Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88860
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.47 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <004101d10844$55f89d90$01e9d8b0$@tutteli.ch>
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>
Date: Fri, 16 Oct 2015 13:40:46 -0600
Message-ID: <CAFMT4NofMWA1pk+eWXMeuQZNnfvBM80feoaajsDDz8UtuKcD=w@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, Andrea Faulds <ajf@ajf.me>, internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: =?UTF-8?B?UmU6IFtQSFAtREVWXSBSZTogW1JGQ10gVm9pZCBSZXR1cm4gVHlwZSAodjAuMiwgcmXDtg==?=
	=?UTF-8?B?cGVuaW5nKQ==?=
From: levim@php.net (Levi Morrison)

On Fri, Oct 16, 2015 at 12:56 PM, Robert Stoll <php@tutteli.ch> wrote:
> Anthony,
>
>> -----Urspr=C3=BCngliche Nachricht-----
>> Von: Anthony Ferrara [mailto:ircmaxell@gmail.com]
>> Gesendet: Freitag, 16. Oktober 2015 17:23
>> An: Robert Stoll
>> Cc: Andrea Faulds; internals@lists.php.net
>> Betreff: Re: [PHP-DEV] Re: [RFC] Void Return Type (v0.2, re=C3=B6pening)
>>
>> 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 =3D null -- ActionScript -- unit
>> > type =3D undefined -- and Swift -- unit type =3D 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 uni=
t 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 explicitl=
y 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 implici=
tly) 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 expli=
citly.
>> > 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 on=
e 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 =3D partialLeft(function(string $a, string $b): void {
>>     syslog(LOG_INFO, $a . ": " . $b);
>> });
>>
>> $log =3D $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 dup=
licated, 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 calla=
ble, then I could argue that the same applies for passing null to partialLe=
ft.
> 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.

While I may be in favor of typing callable signatures, I do want to
point out that the version that is typeless just works, and adding
types didn't work. To me this means the chosen type didn't accurately
portray the semantics. 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 =E2=80=93 it just passes whatever the result was.