Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73845
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: <535FBCA0.90106@garfieldtech.com>
Date: Tue, 29 Apr 2014 09:52:16 -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>	<535ECB9E.5050701@garfieldtech.com> <CAFMT4Np=Nert9ONEns45=v7rg7HdaWi9dxqrxuEBLYT4V2-gyA@mail.gmail.com>
In-Reply-To: <CAFMT4Np=Nert9ONEns45=v7rg7HdaWi9dxqrxuEBLYT4V2-gyA@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, 8:19 PM, Levi Morrison wrote:

>>> 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.

In other words, "let's punt on that until we figure out generics".  With 
the new error message in the RFC I can work with that.  Thanks.

--Larry Garfield