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

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