Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73836
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: <535ECB9E.5050701@garfieldtech.com>
Date: Mon, 28 Apr 2014 16:43:58 -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>	<535E9AED.2080904@garfieldtech.com> <CAFMT4NqP5fB4PMWn6_uWtpG=MtukMheXjd7epX4Jz7sQdydGOQ@mail.gmail.com>
In-Reply-To: <CAFMT4NqP5fB4PMWn6_uWtpG=MtukMheXjd7epX4Jz7sQdydGOQ@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/28/14, 3:30 PM, Levi Morrison wrote:

>> 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.

So I suppose technically we should say that a generator must always 
return a Traversable?

>> 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.

That makes sense from an engine point of view, certainly.  From a user 
POV, I can still see it being the source of much confusion.  I confess 
I've barely used generators so far (PHP 5.5 still having very small 
market penetration), but it feels natural to mentally align return type 
/ return keyword and return type / yield keyword.  It also means I have 
no way of declaring that a generator will always return items of type X, 
which seems like a valid thing to do.

> 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.

I would agree, and look forward to seeing their reasoning.

--Larry Garfield