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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
