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

On 10/14/2015 06:30 PM, Andrea Faulds wrote:

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.

Well, that depends on the intent here. In practice, is the intent to add a "no return at all" type of function (ie, $a = foo() is a syntax error now where it was not before), or to make it explicit that the only legal return is null (even if implicitly that means having a non-early return statement is pointless)? Those are the two options. That may or may not dictate the keyword that gets used. It definitely sounds like you're favoring the second (as that's what the RFC says). Which may or make not make "void" an odd keyword to choose when what's actually happening is NULL getting returned. Is NULL a void? (There's a deep philosophical question...) As I said, I don't have a strong opinion on the subject yet. I'm just trying to distil the discussion down to as small a question as possible. :-) Cheers. --Larry Garfield