Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88814
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 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>
Message-ID: <561FB968.7040601@mabe.berlin>
Date: Thu, 15 Oct 2015 16:34:16 +0200
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: <561EE2F1.7050305@garfieldtech.com>
Content-Type: multipart/alternative;
 boundary="------------020900010903000007070201"
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_[RFC]_Void_Return_Type_=28v0.2=2c_re=c3=b6p?=
 =?UTF-8?Q?ening=29?=
From: dev@mabe.berlin (Marc Bennewitz)

--------------020900010903000007070201
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit



On 10/15/2015 01:19 AM, Larry Garfield wrote:
> 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. >
Option 4)

// implicit return void
function foo () { return; }

// explicit return void
function foo () : void { return; };

// syntax error if returning something on explicit return void
function foo () : void { return null; };

// syntax error on using return value of explicit return void
function foo () : void { return; };
$bar = foo();

// return NULL on implicit return void (this could also give a 
warning/notice/deprecated error)
function foo () { return; };
$bar = foo(); // NULL

// mixing return void with any other return values could also result in 
a warning/notice/deprecated error
function foo () { if ($bar) return; return $bar; };

> --Larry Garfield  >

I really like this as in my opinion if a function doesn't return 
something it should be part of the function signature and it really 
helps to avoid mistakes on writing code.

Marc



--------------020900010903000007070201--