Hi Internals,
Stanislav Malyshev wrote:
> every PHP function actually returns
> something (at least null). So this type would not actually be right and
> would not reflect what actually is happening.
Well obviously we would need to have a followup RFC to make void
functions not have a usable return value! /s
I drafted this email a week ago and didn't send it as I though it was
too snarky to be a useful thing to add to the conversation, but it
seems that it has come up:
François_Laupretre wrote:
> Is it too late to add a note in the RFC, listing the possibility, in the
> future, to forbid using the result of void functions in expressions.
This is an idea that this RFC obviously leads to, but one that is very bad.
Being able to call a function dynamically and not need to determine
whether it is 'void' return type eliminates a whole class of errors
that can occur when calling code dynamically.
function timeFoo(callable $fn) {
startTime();
$result = $fn();
endTime();
return $result;
}
This can be done without any inspection on what the return type of
`$fn` is, and is one of the things that PHP got right.
And yes, if we don't make that change, using the pseudo-type of 'void'
instead of 'null' is going to be an instant source of PHPSadness.
Q: This function has a 'void' return type but it's actually returning null?
A: Yes.
Q: Shouldn't it have a 'null' return type?
A: Apparently they chose to make the language follow the manual rather
than make the manual follow the language.
Q: ...Is it too early to start drinking yet?
Tring to 'clean this up' by preventing a void function being used as
an expression, is an example of making the program follow the PHP
manual's convention, rather than making the manual document what the
engine does.
Levi Morrison wrote:
> 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.
I think this is an important point, and so to try and expand on this a
bit; if you have a function that does not return a value or has a
void/null return type, then this code:
logResult(foo());
is valid.
The person who wrote the function 'foo' might not anticipate that the
function would be used in that way but that is valid code. It is only
when you actually try to use the value as anything other than null
that it becomes a problem i.e.
function findUserbyId(int $userId) {...}
findUserbyId(foo());
it's when you pass the null value to function that needs a non-null
value that the error occurs.
Although alerting someone that they are using a null value where they
actually need another type is a useful thing, we do not need another
type (or pseudo-type) to do this. We should add null as a return type
rather than void as null:
* accurately describes what is happening in the engine, instead of
being an instant source of confusion.
* is compatible with the proposed 'nullable return types' and/or
'union types', void isn't.
* avoids adding a new pseudo-type just for a single use case.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
