Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88858
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: fail (pb1.pair.com: domain tutteli.ch does not designate 80.74.154.80 as permitted sender)
To: "'Anthony Ferrara'" <ircmaxell@gmail.com>
Cc: "'Andrea Faulds'" <ajf@ajf.me>,
	<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>
In-Reply-To: <CAAyV7nG9UyDr1AA5xEK1DYnQ7mLrX95ZNWoZWp421KuUscBmYA@mail.gmail.com>
Date: Fri, 16 Oct 2015 20:56:15 +0200
Message-ID: <004101d10844$55f89d90$01e9d8b0$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIlm6HitWabnDu1qXRDdKGyTlYfFAGnR/YjAXC9KW0A7mbEgZ2lGFpA
Content-Language: de-ch
Subject: =?UTF-8?Q?AW:_=5BPHP-DEV=5D_Re:_=5BRFC=5D_Void_Ret?=
	=?UTF-8?Q?urn_Type_=28v0.2=2C_re=C3=B6pening=29?=
From: php@tutteli.ch ("Robert Stoll")

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)
>=20
> Robert,
>=20
> > 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 =
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.
>=20
> I dislike this, because it punishes dynamic code (function =
composition).
>=20
> For example:
>=20
> $logUtility =3D partialLeft(function(string $a, string $b): void {
>     syslog(LOG_INFO, $a . ": " . $b);
> });
>=20
> $log =3D $log("Prefix");
> $log("blah"); // writes "Prefix: blah" to the log
>=20
> function partialLeft(callable $cb) {
>     return function($left) use ($cb) {
>         return function($right) use ($cb, $left) {
>             return $cb($left, $right);
>         };
>     };
> }
>=20
> Boom, notice.
>=20
> 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.
>=20
> 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...
>=20
> That's just my $0.02
>=20
> 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.=20
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.