Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88803
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
To: internals@lists.php.net
References: <0A.C2.33697.6AECE165@pb1.pair.com> <561ED07E.4060809@gmail.com>
 <CAFMT4NpETZp5p+yVmUNZHjKamkA1niapAs10fCzd-6O0jHk4nA@mail.gmail.com>
 <C6.F6.33697.39EDE165@pb1.pair.com> <561EE2F1.7050305@garfieldtech.com>
 <26.08.33697.F95EE165@pb1.pair.com>
Message-ID: <561EFE73.3060602@garfieldtech.com>
Date: Wed, 14 Oct 2015 20:16:35 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <26.08.33697.F95EE165@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_[RFC]_Void_Return_Type_=28v0.2=2c_re=c3=b6p?=
 =?UTF-8?Q?ening=29?=
From: larry@garfieldtech.com (Larry Garfield)

On 10/14/2015 06:30 PM, Andrea Faulds wrote:
> Which I believe gives the following options:
>>
>> 1) Change the language behavior such that
>>
>> function foo() : void { ...}
>> $a = foo();
>>
>> Is a syntax error (because there really was nothing returned to assign),
>> rather than resulting in $a having a value of NULL.
>
> As the RFC notes, this breaks things, and is inconsistent with how PHP 
> already does things.
>
>> 2) Use null as a "type" (which I agree feels weird just saying it), such
>> that:
>>
>> function foo() : null { ...}
>> $a = foo();
>>
>> and
>>
>> function foo() { ...}
>> $a = foo();
>>
>> are identical.  The former would impact the contents of the function
>> (eg, a non-empty return would be a parse error), but the external result
>> is the same ($a == NULL).
>
> This would be strange. The manual doesn't say `null`, and I can't 
> think of any language which uses `null` as the return type in this 
> situation, even when they have the same implicit-null-return behaviour 
> that PHP has (see the email you're replying to).
>
> Also, wouldn't you expect this to behave like existing type hints, and 
> let you return a null value from any source? But that's not what you 
> would actually want, right?
>
> Thanks.

Well, that depends on the intent here.  In practice, is the intent to 
add a "no return at all" type of function (ie, $a = foo() is a syntax 
error now where it was not before), or to make it explicit that the only 
legal return is null (even if implicitly that means having a non-early 
return statement is pointless)?  Those are the two options.  That may or 
may not dictate the keyword that gets used.

It definitely sounds like you're favoring the second (as that's what the 
RFC says).  Which may or make not make "void" an odd keyword to choose 
when what's actually happening is NULL getting returned.  Is NULL a 
void?  (There's a deep philosophical question...)

As I said, I don't have a strong opinion on the subject yet.  I'm just 
trying to distil the discussion down to as small a question as possible. :-)

Cheers.

--Larry Garfield