Hi
Am 2026-01-23 16:47, schrieb Larry Garfield:
As currently written, yes. However, as noted previously in the Context
Manager thread we are open to allowing arbitrary values in the CM
position, which would fall back to just using that value and then
unsetting it. That would effectively replace the `let` syntax entirely
with a unified syntax.
I have also voted No on this RFC, for many of the reasons already
stated:
* The functionality is too limited.
* The functionality is inherently unreliable due to value escape.
For these two I refer to the email I just sent in reply to Arnaud. I
believe that 4 example use cases are by no means an indication of an RFC
being limited in usefulness. Block scoping is a well-established feature
in programming languages and I'm positive that folks will be able to
come up with even more examples of where block scoping would have been
helpful to them to avoid bugs / make their code easier to reason about.
* The syntax is far too non-standard and clumsy.
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?
* Expanding CMs to fully encompass the behavior of this RFC is trivial,
which would avoid redundant and confusing syntax.
The same is true the other way around, possible ideas are listed in the
Future Scope.
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.
Best regards
Tim Düsterhus
