Re: Re: [VOTE] let construct (Block Scoping)

On Sat, Jan 24, 2026, at 12:16 PM, Tim Düsterhus wrote: > My understanding the initial paragraph of your email is that the entire > functionality of the block scoping RFC could be included in the Context > Manager RFC. The Context Manager RFC uses the same "high-level" syntax > of having a dedicated block for declarations - just using using > > instead of let as the keyword and using > => instead of = for an > assignment (the latter of which was considered confusing in the > discussion). I'm sure I must be misunderstanding, because I don't follow > how the syntax of this RFC is "non-standard and clumsy" without this > equally applying to the context manager RFC. Can you rephrase? Block scoping and CMs are related and overlap, but are different things. let, in every language I am aware of that uses it, is an inline part of the variable declaration, and then they do something to resolve the "dead zone" question. Languages that have block scoping have had it from the beginning, so "variable dies at the next }" is built into the language semantics and development culture. Neither is true in PHP. So having a block-esque syntax for "only these special blocks and these special variables get block scoping" is something I have never seen before, and feels very clumsy. CMs are about packaging up setup/teardown logic to make them reusable, and therefore more ergonomic. That setup/teardown can and often does include unsetting variables, but that's not its main purpose. It's just an implementation detail. In every language with such functionality, it is a block level construct. Block scoping as presented here is essentially a "junior, limited CM", with a future scope of adding a Disposable interface to make it a less-limited CM. I fundamentally believe that is the wrong way around, and have already discussed elsewhere (I think) why forcing the context manager (packaged logic) and context variable (the variable(s) that will need cleanup) to be the same value is fundamentally limiting and flawed. I proposed allowing the using syntax to handle non-CM objects specifically to incorporate the "degenerate case" where unsetting is the only meaningful teardown, and thereby avoid the need for a boilerplate new JustUnsetTheThing($thing) for the degenerate cases. CMs can also return $this from enterContext() if appropriate, which would then have the same effect as the Disposable interface. So no matter how you slice it, having a separate CM from context variable provides more flexibility than the proposed let syntax, in a consistent and unified fashion. By tweaking CMs, we can allow it to also cover the simple, degenerate cases that block scoping handles in addition to the more robust options it naturally supports. > I'd also like to note that it was an explicit design goal of the block > scoping RFC to compose nicely with existing control structures to be > generically applicable. This enables several of the example use cases > listed in the RFC. The context manager RFC requires braces and a > proposed special case for try instead of just accepting any > statement > like block scoping does. Due to its composibility, the block scoping RFC > is even compatible with future additions to the language (provided the > future additions follow the established syntax). As an example, pattern > matching comes to mind as another way of "writing into variables". Block > scoping will just work with match: > > let ($x, $y) $result = match ($p) is { > Point(:$z, :$x, y: 4) => "x is $x, y is 4, z is $z", > }; > > to prevent $x and $y from leaking out of the match(). And > similarly to > the foreach() future scope, we could allow > match ($p) let is to > automatically block scope all variables bound by the pattern. thinking_face.gif This is sort of what we were trying to noodle through with the questions about expression-oriented using, but it didn't stick. I would have to talk to Arnaud, but I suppose it's probably possible to allow using to work on an arbitrary construct and inherit its block. I'm quite open to discussing the feasibility of that. It's really unfortunate that both proposals were worked on separately, as I do believe there are good ideas in both. But I would much rather work from the more-flexible design and then short-cut the degenerate cases, as that gives, I believe, a better outcome in the end. --Larry Garfield