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
