Re: [RFC] Context Managers

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