There are two particular semantic advantages of void functions I’m not sure
have been brought up.
A function that always throws an exception can’t have a return value (and
checking for one is also semantically and logically incorrect). Since such a
function won’t ever return by normal means, the caller can't ever receive or
inspect a return value.
A class of functions never return. That is, they always do one of
* infinite loop
* exit();
* pcntl_exec() or exit();
* terminate the process (e.g. trigger SIGKILL or other fatal signal to
its pid)
* terminate the thread (e.g. pecl pthreads Thread->kill())
* (There isn’t actually a facility for doing a setjmp/longjmp from
userspace php, is there?)
* otherwise somehow prevent a return to parent scope
In this case, similar to the function that always throws, testing the return
value is an error. The function *can’t* return, so there should never be
anything to test. (And thus, testing its return value is a semantic error,
which also implies a logic error because the caller is making an invalid
assumption).
As an aside: if functions can somehow be annotated as no-return, static
analysis tools could even flag code following said function calls as dead and
warn about the existence of unreachable code. Wether PHP should add a noreturn
keyword, or if a docblock annotation of a noreturn property should be
“standardized" is a discussion for another time.
Originally coming from a C background, I’ve always appreciated that PHP
functions always had a return value (even if null), because it allowed writing
code such as this:
function method() {
// … preprocess ..
$return = parent::method();
// … postprocess ...
return $return;
}
without needing to know to whether the parent method actually returned anything
or not (and working seamlessly in the case that the parent method changed what
it was returning).
Given the above, and the fact that changing types on parent functions are going
to force a change to child functions anyways, potentially the following three
cases could be allowed:
function func() : void { return someOtherVoidFunc(); }
function method() : void {
// … preprocess ..
$return = parent::method(); //or possibly, some other void function
// … postprocess ...
return $return;
}
$variableNeverRead = voidFunc();
That is: allow “void” to be a write-only variable type, and trigger an error
only if anything actually attempts to do any sort of operation on its value (as
in, you can’t even inspect it to see if it’s void or not). Attempting to assign
into a reference should probably fail immediately.
While I’d kind of like to see that, I’m not really sold on it since if the
parent/called function’s prototype changes, the child/caller is going to have
to change anyway (to account for the types of return values changing), so
limiting that change to only the return type and not also the return itself is
a potentially dubious win given the potential technical complexity involved in
implementing this.
Thoughts?
-John
> On Oct 30, 2015, at 04:38, Chris Riley <t.carn...@gmail.com> wrote:
>
> Hi,
>
> I'm still not sure why we are using void as the return type and not null.
> Null matches behaviour, void just adds another keyword without value.
>
> ~C
>
> On 30 October 2015 at 04:33, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
>
>> On 10/29/2015 08:55 PM, Stanislav Malyshev wrote:
>>> Hi!
>>>
>>>> "void" or "null" as return type would give a 100% guarantee that every
>> possible
>>>> implementation of a given interface won't return any random value. Then
>> it would
>>>> make no difference if the returned value is being used or not, as it
>>>> would always
>>>> be null.
>>>>
>>>> So, it obviously solves the problem presented. There's not much to
>> dismiss here.
>>>
>>> That's what I am having issue with. I don't see the case where such
>>> guarantee is useful. If you're not using the return value, why do you
>>> care if it's always null or sometimes null and sometimes baloney
>>> sandwich? If you need always null, you have it: null. You don't need to
>>> use return value of a function for it.
>>
>> I agree with you Stas, but I still voted yes on this RFC as I don't see
>> the harm in having it. It is more of a hint for the compiler/static
>> analyzers for them to spew warnings/errors than it is a useful feature
>> at runtime. Enough people consider it a missing check mark on the
>> feature list for it to be added.
>>
>> -Rasmus
>>
>>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
