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
