Re: [RFC] Void Return Type (v0.2, reöp ening)

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