Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73834
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 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 14:30:35 -0600
Message-ID: <CAFMT4NqP5fB4PMWn6_uWtpG=MtukMheXjd7epX4Jz7sQdydGOQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01294d0c13aca904f8203071
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations
From: morrison.levi@gmail.com (Levi Morrison)

--089e01294d0c13aca904f8203071
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 28, 2014 at 12: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.
>

Thank you.


> 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.
>

The type hint is purposefully not the type of the value returned; a
generator always returns a generator. I will clarify this in the RFC and
maybe adjust the wording in the error message as well to better indicate
this.


> I think this part warrants further consideration.  The rest of the RFC I
> fully look forward to using.
>

Special casing a generator's return type would be an inconsistency in the
design. If you var_dump() something that returns generator it tells you it
is a generator; this should match the type of the return value and anything
else is unexpected. As an example, using a generator to fulfill an Iterator
return type should succeed; special casing the Generator would complicate
the code to achieve this. Special casing the generator would also infringe
on other future ideas, such as adding generics to the language. All in all,
special casing generators doesn't make sense.

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.)


At least in the 2.4 branch of HHVM (which I have installed) they put it
before the use statement. Now that I have thought about this more, this is
a poor decision:

 * use statements are basically parameters at construction time instead of
runtime
 * putting the return type before the use statement looks really ugly

I will attempt to contact the HHVM team (perhaps SaraG) to see if there was
a technical reason for it.

--089e01294d0c13aca904f8203071--