(Apparently only replied to Sebastian while on mobile :)
I know this RFC does not address multiple return types on purpose.
But supposing it's implemented in its current form, what would be a
possible syntax for multiple/mixed return types?
Namely for the usual suspects of string|null, array|null, Class|bool,
or ClassA|ClassB|bool, etc...
Something along those lines.
Cheers
On Mon, Apr 28, 2014 at 7:16 PM, Larry Garfield <larry@garfieldtech.com> wrote:
> On 4/24/14, 10:59 AM, Levi Morrison wrote:
>>
>> My dear Internals friends,
>>
>> I have spent the last month drafting an RFC that allows return types:
>> https://wiki.php.net/rfc/returntypehinting
>>
>> Notable items:
>> - Differences from past RFCs are summarized in the RFC:
>> https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs
>> - The patch includes basic opcache and reflection support. It also has
>> phpt tests.
>> - Informal performance tests indicate that the patch did not fubar
>> performance; if desired a more detailed test can be conducted before
>> voting.
>> - This RFC does not add, modify, or remove keywords at all; this
>> notably
>> excludes type-hints for scalars. Supporting scalar type declarations is
>> outside the scope of this RFC; if you are interested in supporting scalar
>> type declarations please discuss it elsewhere.
>>
>> As a friendly reminder, everyone on this list is interested in developing
>> a
>> better PHP and the definitions of 'better' vary from person to person.
>> Please be civil and constructive while discussing this RFC. Thank you!
>>
>> Some thanks, regardless if the RFC is accepted:
>> - For providing a patch: Joe Watkins.
>> - For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
>> Anthony Ferrara
>> - For previous RFCs on this topic: Felipe Pena and Will Fitch. I
>> gleaned
>> valuable knowledge from your proposals and the discussion around them.
>
>
> Simple, targeted, focused, I like. I very much like the NULL handling, as
> it means as a caller I have to do less work.
>
> One bit strikes me as odd. In the invalid examples, you have this example:
>
> function foo(): array {
> yield [];
> }
>
> which generates this error:
>
> Fatal error: Generators may only yield objects, array is not a valid type in
> %s on line %d
>
> Except Generators can totally yield arrays currently:
>
> function foo() {
> yield [];
> }
> foreach (foo() as $x) print_r($x) . PHP_EOL;
>
> The above works perfectly on 5.5.10, where I just tested it.
>
> So what's with that error condition? Clearly from the RFC we can specify
> array as a return type, so I don't know why it calls out generators as
> specially limited.
>
> As I write that I suspect it's because generators actually "return" an
> interator object, and so the return type of the generator is being
> interpreted relative to the construction, not iteration, of the generator.
> That seems like a likely source of confusion, as I would, as a developer,
> expect to be specifying the type that gets returned from iteration, not from
> construction, so that my foreach loop (or similar) can rely on the type
> being returned.
>
> I think this part warrants further consideration. The rest of the RFC I
> fully look forward to using.
>
> As far as the order of keywords in a closure, what order does Hack use? The
> rest of the syntax seems based on it, so it seems sensible to follow suit.
> (I couldn't find that information from 60 seconds on hacklang.org, but it
> may be there.)
>
> --Larry Garfield
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>