Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88938
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: "'Larry Garfield'" <larry@garfieldtech.com>,
	<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> <562AB638.1090304@garfieldtech.com>
In-Reply-To: <562AB638.1090304@garfieldtech.com>
Date: Mon, 26 Oct 2015 11:10:47 +0100
Message-ID: <00e801d10fd6$95b3c6a0$c11b53e0$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIlm6HitWabnDu1qXRDdKGyTlYfFAGnR/YjAXC9KW0A7mbEgQH3VZCOAjVnauCdktTSYA==
Content-Language: de-ch
Subject: =?UTF-8?Q?AW:_AW:_=5BPHP-DEV=5D_Re:_=5BRFC=5D_Void?=
	=?UTF-8?Q?_Return_Type_=28v0.2=2C_re=C3=B6pening=29?=
From: php@tutteli.ch ("Robert Stoll")

Hi Larry,

> -----Urspr=C3=BCngliche Nachricht-----
> Von: Larry Garfield [mailto:larry@garfieldtech.com]
> Gesendet: Samstag, 24. Oktober 2015 00:36
> An: internals@lists.php.net
> Betreff: Re: AW: [PHP-DEV] Re: [RFC] Void Return Type (v0.2, =
re=C3=B6pening)
>=20
> 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 =3D 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 =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
> >> 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.
>=20
> 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).
>=20
> 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:
>=20
> function foo() : void {}
> $a =3D foo();
>=20
> triggering an error condition would make life drastically more =
difficult for higher order function operations like partials or
> memoization.  That seems doubleplusungood.
>=20
> 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. :-)
>=20
> 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).
>=20
> --Larry Garfield
>=20
> --

Well, it really depends on the use case. I would probably not write such =
a generic partial function, especially not allowing functions which =
return a value and others which don't. I could imagine to use =
callable:mixed to allow values of arbitrary types to be returned. Yet, =
that would still not include a function which does not return a value. =
IMO we do not really proceed further with this RFC when discussing this =
special case - callable:int, callable:mixed etc is not supported by PHP =
now, so we should focus on the essential now.

IMO we should get an agreement what void means in PHP, I see the =
following options:

1 void is a type with a value set containing null (ergo corresponds to =
the set { null }) and hence it is perfectly fine to return null from a =
function with return type void (naming it void is controversial among =
the list -- others prefer null -- but that can be discussed further =
afterwards)
2 void is a type with an empty value set (a special value respectively) =
and hence one cannot return null from a function with return type void =
and
  a) such a function returns null implicitly nonetheless
  b) such a function returns a special value which triggers a fatal =
error when it is accessed

IMO 2a is inconsistent and I would only consider 1 or 2b