Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88800
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>
Message-ID: <561EE2F1.7050305@garfieldtech.com>
Date: Wed, 14 Oct 2015 18:19:13 -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: <C6.F6.33697.39EDE165@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:00 PM, Andrea Faulds wrote:
> Both you and Stas have said this, but it's only true if we solely 
> consider C-like languages. Other languages do different things. In the 
> PHP manual, Hack, TypeScript, ActionScript, and most likely other 
> languages (these are just off the top of my head), `void` functions do 
> still have an implicit result.
>
> All of these languages would have had the choice to do what you're 
> suggesting and use `null`, or its equivalent (`undefined` for 
> TypeScript and ActionScript). They didn't. Why? If I had to guess, 
> there's at least three reasons. For one, void is the word languages 
> usually use for this. For another, `void` and `null` they mean 
> different things. `void` signifies a function isn't returning 
> anything. `null` signifies a function that *returns null*, regardless 
> of where that null came from. `function foo(): null { return 
> some_probably_null_returning_function(); }` should surely be legal 
> with a `null` type hint, yet it's nonsensical code. Finally, making a 
> function truly "return nothing", i.e. disallowing its use as an 
> expression/rvalue, breaks some use cases, like passing along the 
> result of a callback.
>
> PHP would neither be the first nor the last to be using `void` in this 
> way.
>
>> If the union types RFC[2] passes it
>> makes sense to allow `Foo | null` which allows something of type `Foo`
>> or `null`. To me it makes sense that if you then remove `Foo` you are
>> left with `null`, not `void`. My personal recommendation because of
>> this would be to use `null` for the return type and instead of `void`.
>
> `null` would be a weird type, because it doesn't make sense as a 
> parameter type, and as a return type, you don't really want to enforce 
> returning null, you want to enforce not returning at all (see the 
> example above). It feels like a poor man's substitute to me.
>
> Thanks.

The tricky part here is that saying a function does not return is not 
something PHP currently does:

https://3v4l.org/HtAuC

No return implicitly returns NULL, which you can assign to a variable 
if, for some strange reason, you were so inclined.  So this would be 
more than "just" a syntactic documentation feature.

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.

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).

3) Use the "void" keyword, but give it the same effect as option 2.

The RFC currently seems to propose option 3 (based on the "Use of void 
functions in expressions" section).  I don't have a strong feeling at 
this point about which option I'd prefer.

--Larry Garfield