Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73832
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <535E9AED.2080904@garfieldtech.com>
References: <CAFMT4NoUZ7==rmLtuohHrddNnurOe-quPL9q_=WbdNV+jo1kYA@mail.gmail.com>
 <535E9AED.2080904@garfieldtech.com>
Date: Mon, 28 Apr 2014 19:18:28 +0100
Message-ID: <CA+yzxZjOTpZUnGPYOa_qP7g0J_L7HppS83s6h4nHzmyLUkPKeA@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations
From: admacedo@gmail.com (Daniel Macedo)

(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
>