Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88927
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.29 cause and error)
To: internals@lists.php.net
References: <0A.C2.33697.6AECE165@pb1.pair.com>
 <11.10.09496.8F410265@pb1.pair.com>
 <001b01d107f1$9d672370$d8356a50$@tutteli.ch>
 <CAAyV7nG9UyDr1AA5xEK1DYnQ7mLrX95ZNWoZWp421KuUscBmYA@mail.gmail.com>
 <004101d10844$55f89d90$01e9d8b0$@tutteli.ch>
Message-ID: <562AB638.1090304@garfieldtech.com>
Date: Fri, 23 Oct 2015 15:35:36 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <004101d10844$55f89d90$01e9d8b0$@tutteli.ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: =?UTF-8?Q?Re:_AW:_[PHP-DEV]_Re:_[RFC]_Void_Return_Type_=28v0.2=2c_r?=
 =?UTF-8?Q?e=c3=b6pening=29?=
From: larry@garfieldtech.com (Larry Garfield)

On 10/16/2015 11:56 AM, Robert Stoll wrote:
>>> 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