Like I said in a previous post, there is no need to forbid using a void
function return value.
Throwing an E_NOTICE would be sufficient to inform the developer he's doing
something weird (using the return value from a function that, by
definition, shouldn't have any return value) without breaking away from
what PHP already does (returning null when a return is absent) and still
being perfectly in line with when people access values from undefined
things (like an uninitiated variable, which throws E_NOTICE and returns
null).
2015-10-29 10:44 GMT-02:00 Dan Ackroyd <dan...@basereality.com>:
> 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
>
>
