Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73837
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <535ECB9E.5050701@garfieldtech.com>
References: <CAFMT4NoUZ7==rmLtuohHrddNnurOe-quPL9q_=WbdNV+jo1kYA@mail.gmail.com>
	<535E9AED.2080904@garfieldtech.com>
	<CAFMT4NqP5fB4PMWn6_uWtpG=MtukMheXjd7epX4Jz7sQdydGOQ@mail.gmail.com>
	<535ECB9E.5050701@garfieldtech.com>
Date: Mon, 28 Apr 2014 19:19:57 -0600
Message-ID: <CAFMT4Np=Nert9ONEns45=v7rg7HdaWi9dxqrxuEBLYT4V2-gyA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133177ce163f604f8243a5d
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations
From: morrison.levi@gmail.com (Levi Morrison)

--001a1133177ce163f604f8243a5d
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 28, 2014 at 3:43 PM, Larry Garfield <larry@garfieldtech.com>wrote:

> 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?


Not quite: a generator always returns a Generator (this is an actual
object); so it can fulfill Generator, Iterator and 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.


Agreed; however I would rather have all kinds of Iterators and collection
like object be able to type their values too. This would obviously fall
outside of this RFC so I have specifically left this possibility open
without directing its future too much.

--001a1133177ce163f604f8243a5d--