[VOTE] let construct (Block Scoping)

Hi,

Le sam. 24 janv. 2026 à 18:35, Tim Düsterhus tim@bastelstu.be a écrit :

Am 2026-01-24 15:13, schrieb Arnaud Le Blanc:

and thats what people writing cleanup critical code rely on already.
This gives a much nicer syntax.

In my experience, relying on this causes occasional bugs that are
unusually difficult to address (and to avoid in the first place).

The RFC lists 4 possible use cases within the example section:

I agree that the RFC adresses 3 of these use cases, but I regret that the
pitfall in the last one is being dismissed or minimized, while claiming to
address that use case. There is enough evidence in other languages that the
pitfall is real and common, as features claiming to address the use case
are designed explicitly to avoid it.

This leaves the locking example

This is a simple one, but most code will send the scoped resource to other
functions to perform anything useful, increasing the risk of capture.

The future scope lists improvements as next steps, like the error when

RC > 1 or Disposable interfaces, this is a first step towards

something that is missing dearly.

Unfortunately these improvements won't make it because they will be
breaking changes.

This is false. We would not list anything as "Future Scope" when it

would be a breaking change. Both the RC > 1 and the Disposable interface

would require the author of the resource class to add an interface for
the corresponding functionality to become active and would therefore be
fully opt-in. Adding new symbols (incl. interfaces) to PHP is not
considered a breaking change as per our policy:

https://github.com/php/policies/blob/main/release-process.rst#backward-compatibility
.

The issue is that implementing Disposable on existing objects after the
fact is a BC break as by then some code may rely on the fact that disposal
is not enforced. This precludes making any exiting object (or streams)
Disposable if that interface is introduced later, because this might break
people’s code. Making it opt-in in the let() syntax is a potential solution
to that, but it’s error prone.

For disposal, only if we decide so. The RFC proposes to introduce

block scoping, and could have made the decision to deterministically
dispose of values as they go out of scope.

See above: This would possibly break at least one of the presented use
cases of the RFC.

As you said this would be opted in by implementing Disposable.

The RFC refers to similar features in Python and Hack, with the same

basic syntax, both of which use reference counting as primary garbage
collection mechanism, yet disposal is deterministic in this context.

The "References" section is non-normative with regard to the proposal
itself and just supplies supplementary information. My previous email
provides further context to the listed references:
https://news-web.php.net/php.internals/129202.

I know, but making comparisons is natural as the RFC claims to address the
same use cases. Based on the previous thread it feels like the design was
adapted to borrow principles from Rust (objects can be disposed only when
unreachable), but PHP doesn’t have features that would make this reliable,
like explicit lifetimes. I think that the way that languages closer to
PHP implement this use case would fit PHP better.

Best Regards,
Arnaud

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