Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73831
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
Message-ID: <535E9AED.2080904@garfieldtech.com>
Date: Mon, 28 Apr 2014 13:16:13 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAFMT4NoUZ7==rmLtuohHrddNnurOe-quPL9q_=WbdNV+jo1kYA@mail.gmail.com>
In-Reply-To: <CAFMT4NoUZ7==rmLtuohHrddNnurOe-quPL9q_=WbdNV+jo1kYA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations
From: larry@garfieldtech.com (Larry Garfield)

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