Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129622
Precedence: list
MIME-Version: 1.0
References: <CAJp_myV9+kxx-eA+cja-Fu5dJhDZgzhgpBpiZFWqqW-_zrNreQ@mail.gmail.com>
 <70A79513-5503-467E-BC6F-2B0494A3EBB9@benramsey.com> <CADK1yXJgPsZJ5+qepDotrMMtRm8TtG95wS7UNpvd8D=Pm-+BOQ@mail.gmail.com>
 <D8927CEA-3D00-4ECF-807B-7C2C96C5B582@rwec.co.uk> <CADK1yXJUt3OLExBT5462mHu_vaxyRuUTKcVYF_kbwY04_y8TJA@mail.gmail.com>
 <cf0dc177-cce8-4703-9195-b91408ba694c@app.fastmail.com>
In-Reply-To: <cf0dc177-cce8-4703-9195-b91408ba694c@app.fastmail.com>
Date: Tue, 16 Dec 2025 13:49:35 -0300
Message-ID: <CADK1yXKCHfNN0ZwALrBMtzftq-5bSFoW9SRhETXDqSfkQGfZdg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Context Managers
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007048f80646148515"
From: deleugyn@gmail.com (Deleu)

--0000000000007048f80646148515
Content-Type: text/plain; charset="UTF-8"

>
> First, yeesh, where were y'all 2 weeks ago? :-P
>

I searched for the `as` vs `=>` discussion on the current thread (ref:
https://externals.io/message/129077) and it didn't exist until now. Then I
found the discussion happened on the Examples comparing Block Scoped RAII
and Context Managers (ref: https://externals.io/message/129251). I wasn't
following that discussion because I thought it was mostly about comparing
both implementations and taking knowledge from it. I didn't expect *that*
to make this RFC to change without it being discussed here.


> Second, I find it fascinating that there's so many different
> mutually-incompatible spins on what => means.  As argued in the
> short-functions and auto-capture-closure RFCs from a few years ago, => in
> nearly all cases currently means "evaluates to."
>
> $arr = [
>   'a' => 'A",
>   'b' => 'B',
> ];
>
> $arr['a'] // This "evaluates to" A
>
> match ($foo) {
>   'a' => 'A',
>   'b' => 'B', // The 'b' case "evaluates to" B
> };
>
> fn($foo) => 'bar'; // This function "evaluates to" bar
>
> foreach ($arr as $k => $v) {}
>
> The last is a little bit inconsistent, but can still be read as "$k, and
> the thing that $k evaluates to."
>

I think the problem might be less about the true meaning of => and more
about the context that it applies to. You can see that in 3 cases of the
arrow it involves some sort of key/value pair (2 array scenarios and 1
match/case). In the case of arrow function, like I said before, arrow
functions are kind of a standard that stand up on their own. And even then,
the "evaluates to" is only partially because in arrow functions the
evaluation does not take immediate effect, it is parsed into a Closure that
needs to be invoked. For instance:

```
$array = [
    'key' => throw new Exception('Stop'),
];
```

Here, the arrow evaluates to an exception that is immediately thrown.

```
match ($foo) {
  'a' => throw new Exception('Stop because of A'),
  'b' => throw new Exception('Stop because of B'),
};
```

Here, the evaluation is more loose and it only takes effect when there is a
match, but it does take effect.

```
fn () => throw new Exception('Stop');
```

Here, the evaluation never takes effect if the Closure is not invoked.

In these 3 cases, we can see each having its own evaluation rule:
immediate, immediate only for the match, and delayed. If I were to put into
words, I'd say:

array keys: evaluates to
match: evaluate to the matched key
arrow function: parse the syntax, does not evaluate to.

```
foreach ($arr as $k => $v) {}
```

Here I don't see it only as a bit inconsistent because it's not really
evaluating anything anymore. It is assigning a value. And this is where it
blows up for me. The first 3 cases we can argue semantics and point of
views, but they are minor nuances. Still, they're all cases where something
on the right is being evaluated for a reason on the left. On foreach, $v
stands on its own. It's not affected / impacted / dicated / evaluated
towards the left at all. It's not a bit inconsistent, it's completely
different. And the syntax for using () is largely similar to foreach, which
is why it should use `as` and not `=>`.

foreach ($iterator as $key => $value)
using ($contextManager as $context)

We can see that the only place where arrow ("evaluates to" / =>) is used
inside an instruction is in foreach and the syntax is split away from the
array itself because the keyword `as` is separating `$k => $v` from the
$iterator. I can totally see an argument for:

using (new ContextManager as $contextManager which evaluates to $context)
using (new ContextManager as $contextManager => $context)

Here, the return of `enter` would be [$this, $context] and the syntax falls
into place with a symmetry from foreach. I wouldn't strongly push for this
syntax because the following also works

using ($manager = new ContextManager as $context)

In any case, I don't have a vote and I really like the RFC in general. With
proper IDE support, I'm sure we will all get used to =>, but from where I
stand that's going to be really awkward for the PHP syntax.

-- 
Marco Deleu

--0000000000007048f80646148515
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">First, yeesh, where were y&#39;all=
 2 weeks ago? :-P<br></blockquote><div><br></div><div>I searched for the `a=
s` vs `=3D&gt;` discussion on the current thread (ref: <a href=3D"https://e=
xternals.io/message/129077">https://externals.io/message/129077</a>) and it=
 didn&#39;t exist until now. Then I found the discussion happened on the Ex=
amples comparing Block Scoped RAII and Context Managers (ref:=C2=A0<a href=
=3D"https://externals.io/message/129251">https://externals.io/message/12925=
1</a>). I wasn&#39;t following that discussion because I thought it was mos=
tly about comparing both implementations and taking knowledge from it. I di=
dn&#39;t expect *that* to make this RFC to change without it being discusse=
d here.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">
Second, I find it fascinating that there&#39;s so many different mutually-i=
ncompatible spins on what =3D&gt; means.=C2=A0 As argued in the short-funct=
ions and auto-capture-closure RFCs from a few years ago, =3D&gt; in nearly =
all cases currently means &quot;evaluates to.&quot;<br>
<br>
$arr =3D [<br>
=C2=A0 &#39;a&#39; =3D&gt; &#39;A&quot;,<br>
=C2=A0 &#39;b&#39; =3D&gt; &#39;B&#39;,<br>
];<br>
<br>
$arr[&#39;a&#39;] // This &quot;evaluates to&quot; A<br>
<br>
match ($foo) {<br>
=C2=A0 &#39;a&#39; =3D&gt; &#39;A&#39;,<br>
=C2=A0 &#39;b&#39; =3D&gt; &#39;B&#39;, // The &#39;b&#39; case &quot;evalu=
ates to&quot; B<br>
};<br>
<br>
fn($foo) =3D&gt; &#39;bar&#39;; // This function &quot;evaluates to&quot; b=
ar<br>
<br>
foreach ($arr as $k =3D&gt; $v) {}<br>
<br>
The last is a little bit inconsistent, but can still be read as &quot;$k, a=
nd the thing that $k evaluates to.&quot;<br></blockquote><div><br></div><di=
v>I think the problem might be less about the true meaning of =3D&gt; and m=
ore about the context that it applies to. You can see that in 3 cases of th=
e arrow it involves some sort of key/value pair (2 array scenarios and 1 ma=
tch/case). In the case of arrow function, like I said before, arrow functio=
ns are kind of a standard that stand up on their own. And even then, the &q=
uot;evaluates to&quot; is only partially because in arrow functions the eva=
luation does not take immediate effect, it is parsed into a Closure that ne=
eds to be invoked. For instance:</div><div><br></div><div>```<br>$array =3D=
 [<br>=C2=A0 =C2=A0 &#39;key&#39; =3D&gt; throw new Exception(&#39;Stop&#39=
;),<br>];<br>```<br><br>Here, the arrow evaluates to an exception that is i=
mmediately thrown.</div><div><br></div><div>```</div><div>match ($foo) {<br=
>=C2=A0 &#39;a&#39; =3D&gt; throw new Exception(&#39;Stop because of A&#39;=
),<br>=C2=A0 &#39;b&#39; =3D&gt; throw new Exception(&#39;Stop because of B=
&#39;),<br>};<br></div><div>```</div><div><br></div><div>Here, the evaluati=
on is more loose and it only takes effect when there is a match, but it doe=
s take effect.</div><div><br></div><div>```</div><div>fn () =3D&gt; throw n=
ew Exception(&#39;Stop&#39;);</div><div>```</div><div><br></div><div>Here, =
the evaluation never takes effect if the Closure is not invoked.</div><div>=
<br></div><div>In these 3 cases, we can see each having its own evaluation =
rule: immediate, immediate only for the match, and delayed. If I were to pu=
t into words, I&#39;d say:<br><br>array keys: evaluates to</div><div>match:=
 evaluate to the matched key</div><div>arrow function: parse the syntax, do=
es not=C2=A0evaluate to.</div><div><br></div><div>```</div><div>foreach ($a=
rr as $k =3D&gt; $v) {}</div><div>```</div><div><br></div><div>Here I don&#=
39;t see it only as a bit inconsistent because it&#39;s not really evaluati=
ng anything anymore. It is assigning=C2=A0a value. And this is where it blo=
ws up for me. The first 3 cases we can argue semantics and point of views, =
but they are minor nuances. Still, they&#39;re all cases where something on=
 the right is being evaluated for a reason on the left. On foreach, $v stan=
ds on its own. It&#39;s not affected / impacted / dicated / evaluated towar=
ds the left at all. It&#39;s not a bit inconsistent, it&#39;s completely di=
fferent. And the syntax for using () is largely similar to foreach, which i=
s why it should use `as` and not `=3D&gt;`.=C2=A0</div><div><br></div><div>=
foreach ($iterator as $key =3D&gt; $value)<br>using ($contextManager as $co=
ntext)</div><div><br></div><div>We can see that the only place where arrow =
(&quot;evaluates to&quot; / =3D&gt;) is used inside an instruction is in fo=
reach and the syntax is split away from the array itself because the keywor=
d `as` is separating `$k =3D&gt; $v` from the $iterator. I can totally see =
an argument for:<br><br>using (new ContextManager as $contextManager which =
evaluates to $context)<br>using (new ContextManager as $contextManager =3D&=
gt; $context)<br><br></div><div>Here, the return of `enter` would be [$this=
, $context] and the syntax falls into place with a symmetry from foreach. I=
 wouldn&#39;t strongly push for this syntax because the following also work=
s</div><div><br></div><div>using ($manager =3D new ContextManager as $conte=
xt)</div><div><br></div><div>In any case, I don&#39;t have a vote and I rea=
lly like the RFC in general. With proper IDE support, I&#39;m sure we will =
all get used to =3D&gt;, but from where I stand that&#39;s going to be real=
ly awkward for the PHP syntax.</div></div><div><br></div><span class=3D"gma=
il_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signatur=
e"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div=
 dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Marco Deleu</div></div></div=
></div></div></div></div></div></div>

--0000000000007048f80646148515--