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

Hi Larry, Larry Garfield wrote:

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 has been pointed out.

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. -- Andrea Faulds http://ajf.me/