[RFC] Void Return Type (v0.2, reöpening)

Hi Rowan,

Rowan Collins wrote:

But why "invent" (as far as PHP is concerned) this new keyword of "void"
to mean exactly the same thing "null" already means - absence of a
definite value?

They don't mean exactly the same thing. null is a value to represent a
lack of a value. But there's also the concept of no value at all (a
missing variable, say). The closest we have to that in PHP already would
actually be unset, but that's a strange choice given it's not what we
use in documentation (function prototypes, PHP manual, PHPDoc, etc. use
void), and it's tainted by the bizarro (unset) cast which casts to null.

Thanks.

--
Andrea Faulds
http://ajf.me/

Korvin Szanto wrote on 14/10/2015 23:55:

If I capture the result of a "void" method and check if my result variable
with isset(), I'll get false. This sounds like it's void of value to me.

But why "invent" (as far as PHP is concerned) this new keyword of "void" to
mean exactly the same thing "null" already means - absence of a definite
value?

It's already "invented" for PHP anyway:
http://docs.hhvm.com/manual/en/hack.annotations.examples.php - example

cheers,
Derick

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/

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

Pedro Cordeiro wrote on 15/10/2015 17:14:

I've been thinking about what PHP should do when accessing the return
value of a void function, and so far, I think the consistent thing
should be to get NULL, while throwing an E_NOTICE.

$a = $b; //$b wasn't initiated.

This does the same thing. I tried accessing what was supposed to be
'nothing' ($b), and got NULL with an E_NOTICE being thrown.

function myFunc() : void { ... }
$a = myFunc();

I see no reason why this should silently assign NULL to $a,
specially with "return null;" being explicitly forbidden. ... The
behaviour should be consistent (NULL should be accessed, as for all
undefined things), with an E_NOTICE.

I don't know how easy this would be to implement, but I agree that this
would make the "void" keyword feel more meaningful.

Does the Engine have a way to know whether a return value is being used
or discarded for optimisation purposes? If so, could that logic be
hooked to provide the Notice?

Regards,

Rowan Collins
[IMSoP]

Hi Pedro,

Pedro Cordeiro wrote:

I've been thinking about what PHP should do when accessing the return value
of a void function, and so far, I think the consistent thing should be to
get NULL, while throwing an E_NOTICE.

We could do this, but I do wonder if it might cause a lot of E_NOTICEs
to pop up for existing code, assuming we applied this to built-in PHP
functions.

I'm not sure.

Thanks.

Andrea Faulds
http://ajf.me/

Anthony,

-----Ursprüngliche Nachricht-----
Von: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Gesendet: Freitag, 16. Oktober 2015 17:23
An: Robert Stoll
Cc: Andrea Faulds; internals@lists.php.net
Betreff: Re: [PHP-DEV] Re: [RFC] Void Return Type (v0.2, reöpening)

Robert,

You write in your RFC "others do allow void functions in expressions,
just as PHP does, by making them implicitly return some unit type."
You mentioned TypeScript -- unit type = null -- ActionScript -- unit
type = undefined -- and Swift -- unit type = empty tuple, ergo ().
TypeScript [1] allows to return null, ActionScript does not allow to
return undefined, and Swift allows to return an empty tuple explicitly [2].

I agree with others that is seems inconsistent to use the name void
but allow to use void functions in expression (return implicitly a unit type) and in the same time forbid to return the unit
type explicitly in such functions.
IMO ActionScript should have allowed to return the unit type explicitly as well and so should PHP.
At first I did not like the idea of introducing void in PHP at all if
it has not the same behaviour as in C -- meaning it should be
forbidden to use void functions in expressions -- but now I think it
better suits PHP if void stands for return nothing (hence null implicitly) or null explicitly. I think you should change your
RFC to allow returning explicitly null for two reasons:

1. Implicit and explicit behaviour should be consistent. If a function
   returns null implicitly then it should be allowed to return null explicitly.
2. Not everyone might be aware of the implicit behaviour and some code
   conventions might want to be explicit on this part and dictate that one needs to express the behaviour in code.

To conclude, personally I want that the following are all equivalent:
function foo() : void {}
function foo() : void { return; }
function foo() : void { return null; }

To go a step further, I kind of like the idea that using the return
value of a void function results (at least) in an E_NOTICE. But maybe that is something for PHP 8.

I dislike this, because it punishes dynamic code (function composition).

For example:

$logUtility = partialLeft(function(string $a, string $b): void {
syslog(LOG_INFO, $a . ": " . $b);
});

$log = $log("Prefix");
$log("blah"); // writes "Prefix: blah" to the log

function partialLeft(callable $cb) {
return function($left) use ($cb) {
return function($right) use ($cb, $left) {
return $cb($left, $right);
};
};
}

Boom, notice.

Now, we could say that "that's the problem of the caller of partialLeft", but the notice is raised inside of the closure inside
of partialLeft. Which would imply that it did something wrong. Something that it couldn't possibly know about without
booting a reflectionfunction for it.

This would mean that generic higher order functions would need to be duplicated, one for void functions and one for non-
void functions. A bit overkill...

That's just my $0.02

Anthony

I agree only to a certain degree. If you had not used the type hint callable, then I could argue that the same applies for passing null to partialLeft.
Hence, the problem is rather that PHP does not yet support callable type hints with return type, something like callable:int, in which case it would be clear that the error was done by the caller.

While I may be in favor of typing callable signatures, I do want to
point out that the version that is typeless just works, and adding
types didn't work. To me this means the chosen type didn't accurately
portray the semantics. This is one reason I am in favor of null
instead of void. Void does not accurately portray the semantics in
my opinion. If the return type was null instead of void there would be
no issue. Sure, the return value would be null, but partialLeft
doesn't care – it just passes whatever the result was.

You write in your RFC "others do allow void functions in expressions,
just as PHP does, by making them implicitly return some unit type."
You mentioned TypeScript -- unit type = null -- ActionScript -- unit

To conclude, personally I want that the following are all equivalent:
function foo() : void {}
function foo() : void { return; }
function foo() : void { return null; }

To go a step further, I kind of like the idea that using the return
value of a void function results (at least) in an E_NOTICE. But maybe that is something for PHP 8.
I dislike this, because it punishes dynamic code (function composition).

For example:

$logUtility = partialLeft(function(string $a, string $b): void {
syslog(LOG_INFO, $a . ": " . $b);
});

$log = $log("Prefix");
$log("blah"); // writes "Prefix: blah" to the log

function partialLeft(callable $cb) {
return function($left) use ($cb) {
return function($right) use ($cb, $left) {
return $cb($left, $right);
};
};
}

Boom, notice.

Now, we could say that "that's the problem of the caller of partialLeft", but the notice is raised inside of the closure inside
of partialLeft. Which would imply that it did something wrong. Something that it couldn't possibly know about without
booting a reflectionfunction for it.

This would mean that generic higher order functions would need to be duplicated, one for void functions and one for non-
void functions. A bit overkill...

That's just my $0.02

Anthony
I agree only to a certain degree. If you had not used the type hint callable, then I could argue that the same applies for passing null to partialLeft.
Hence, the problem is rather that PHP does not yet support callable type hints with return type, something like callable:int, in which case it would be clear that the error was done by the caller.

That wouldn't help either, I think. Then you'd need a separate
partialLeft(callable:int $cb), partialLeft(callable:string $cb),
partialLeft(callable:float $cb), and partialLeft(callable:void $db). And
likely others. That seems exactly like what Anthony wants to avoid
(rightly).

Indirect calls to arbitrary functions does mean that they need to be
able to behave consistently when referred to abstractly. Vis, any
approach that involves:

function foo() : void {}
$a = foo();

triggering an error condition would make life drastically more difficult
for higher order function operations like partials or memoization. That
seems doubleplusungood.

One way around that would be to only trigger that behavior on a static
call, not a call to a variable function, but I have no idea if that's at
all feasible in the engine. I suspect it's more feasible than detecting
the function wrapping and only erroring at the top level caller, but now
I'm just talking out of my butt. :-)

That leaves "documentation of intent for the developer" (which is a
valid argument) and "slap someone's hand for returning non-null inside
the function itself" (which is valid, but leaves the question of whether
return null should error).

--Larry Garfield