Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113795
Message-ID: <CF8025BC-B86C-44CF-950B-8C6FBD124206@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A589D705-BED4-4AB8-9BE7-ED01172B4A03"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 25 Mar 2021 14:28:55 -0400
In-Reply-To: <CAPKYkKy-ovBmNvrG3GQcxRwX3Y+4Fpu_oK2AL0AOfUuLph5+VA@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Chase Peeler <chasepeeler@gmail.com>
References: <88c9eb5f-f80c-4869-b7f8-1b58b9e2eaa3@www.fastmail.com>
 <CAF+90c9PRmK1FM_uUO3qMhhvMybY4z_aZkmMO53TVfuy--U32g@mail.gmail.com>
 <CAPKYkKxTgHnzXKwkHi4qgJewY86vWFehrhN39fyrrK5KWNVvig@mail.gmail.com>
 <4DC3B66E-A91A-4AA9-8872-8EE9DE92C2D4@cschneid.com>
 <8c72c162-83c0-7c7f-2fa7-4fbe3fb30a4a@gmail.com>
 <605bae82.1c69fb81.f49f7.d11eSMTPIN_ADDED_MISSING@mx.google.com>
 <919e30e7-3e5e-d955-7bb4-1e1b5825cdd1@gmail.com>
 <635DD146-FC6F-4991-8D2C-5A6B492722D5@newclarity.net>
 <734f12de-da98-6b76-c2fe-8682f4d177aa@gmail.com>
 <CALZWoqXZF9wegVGwGMjjVEV89zTjb-TYS87MqP36fSk-qJqD4g@mail.gmail.com>
 <daffe9ec-3163-25cc-bb52-587fbd2230bb@gmail.com>
 <36E45DD6-E2BD-4801-BAAE-4355C83D1AC3@newclarity.net>
 <ca1df8f5-18c9-f333-93c7-ba81d3ca3ea4@gmail.com>
 <538F5888-4B42-42AA-8312-872A836B0FB9@newclarity.net>
 <CAPKYkKy-ovBmNvrG3GQcxRwX3Y+4Fpu_oK2AL0AOfUuLph5+VA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and
 shortfunctions take 2
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_A589D705-BED4-4AB8-9BE7-ED01172B4A03
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Mar 25, 2021, at 1:19 PM, Chase Peeler <chasepeeler@gmail.com> =
wrote:
>=20
> On Thu, Mar 25, 2021 at 1:14 PM Mike Schinkel <mike@newclarity.net =
<mailto:mike@newclarity.net>> wrote:
> > On Mar 25, 2021, at 12:50 PM, Rowan Tommins <rowan.collins@gmail.com =
<mailto:rowan.collins@gmail.com>> wrote:
> >=20
> > On 25/03/2021 15:02, Mike Schinkel wrote:
> >> Can you please clarify why "function(...) use(...) {...}" can't be =
their solution when someone needs by-reference capture?
> >=20
> >=20
> > For the same reason - or lack of reason - why it can't be the =
solution when they need by-value capture. In other words, whatever =
reason people have for wanting this RFC.
>=20
> Are you proposing auto-capture but one that is note able to change the =
variable's value in the outer scope? =20
>=20
> Since code is worth 1000 words, here is an example of what I think you =
are saying:
>=20
>     $x =3D 1;
>     example(fn() {
>        echo $x; // This would print "1"
>        $x =3D 2;
>        echo $x; // This would print "2"
>     });
>     echo $x;  // This would still print "1"
>=20
> If that is what you are saying =E2=80=94 which I did not get from your =
prior arguments =E2=80=94 then I myself would be fine with "by-value" =
capture.
>=20
> What I like about the RFC is being able to omit the use(...) when =
referencing (reading) a variable inside the closure that come from the =
outer scope.  But almost all of my use-cases would work fine with =
by-value semantics, and for the rest I could use =
"function(...)use(...){...}."
>=20
> That said, I again suggest this we could omit the "use" keyword for =
short functions: =20
>=20
>     // 2nd set of parens acts as an implied "use":
>     example( fn()(&$var) =3D> $var =3D value() );
>=20
>=20
> That wouldn't work though if example expects a callback with a defined =
signature. "Use function() use()" in that case might be a valid =
solution, but just wanted to throw it out there.


True.  But is that really any different than this failing:

	example(1);

When the signature is this?

	example(string $x) {...}

-Mike


--Apple-Mail=_A589D705-BED4-4AB8-9BE7-ED01172B4A03--