Re: 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