Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129623
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 16 Dec 2025 11:55:31 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <1d59c5df-b7e9-402e-bb91-667f9910ba8c@app.fastmail.com>
In-Reply-To: 
 <CADK1yXKCHfNN0ZwALrBMtzftq-5bSFoW9SRhETXDqSfkQGfZdg@mail.gmail.com>
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>
 <CADK1yXKCHfNN0ZwALrBMtzftq-5bSFoW9SRhETXDqSfkQGfZdg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Context Managers
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Dec 16, 2025, at 10:49 AM, Deleu wrote:

> 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

Well, in the vast majority case there will be no need to access the CM within the `using` block.  If there is, then it's likely that enterContext() will be returning just $this already.  So the $contextManager variable is unnecessary noise 99% of the time.

But if we take that out, which get right back to:

using (new ContextManager => $context)

I suppose grammatically this would make sense:

using (new CM() yields $v)

But that's a new keyword that is very close to an existing keyword that means something totally different, so probably not the best idea.

> In any case, I don't have a vote and I really like the RFC in general. 

Yay!

--Larry Garfield