Hi
Reordering the quoted parts to improve the structure of the reply.
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:
a) Example showing an edge case (solving the foreach reference bug)
Here the goal is not to destruct the underlying value, but to free up the variable name for reuse.
b) Example showing the combination of let and if()
The same applies here. The goal is to prevent accidental use of a variable after it is no longer meant to be used. The stored value will not have special destruction logic attached.
c) Example showing memory-efficient batch processing
For this one the concern is "memory consumption". To my understanding you considered this a safe use case for reference counting in php.internals: Re: [RFC][Discussion] use construct (Block Scoping).
d) Example showing reliable resource management
This leaves the locking example, where the object guards a non-memory resource that might accidentally be captured. In my experience developing PHP, I never had an issue with accidental escapes of resource objects and I feel that keeping them in a local variable is sufficiently robust to prevent them from accidentally being captured.
I acknowledge that your experience was different than mine, that's why the RFC lists possible improvements to make this easier/safer as future scope.
The RFC proposes a generically applicable language feature that solves example use cases (a), (b), (c) perfectly fine as-is. It is no worse than existing solutions for (d) and leaves a clear path for future scope ideas to support (d) even better. I feel that reducing it to just the "lock example" / "external resource management" is not doing the RFC justice.
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: policies/release-process.rst at main · php/policies · GitHub.
Throwing for every RC > 1 object at the end of the `let()` block would break the "let ($user = $repository->find(1)) if ($user !== null)" use case if the repository internally uses an identity map and thus keeps a reference to all objects it hands out. Any special `Disposable` handling for a user object would also break the identity map, because it now stores an object that already was disposed and thus likely is in an invalid state.
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.
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: php.internals: Re: [RFC][Discussion] use construct (Block Scoping).
Best regards
Tim Düsterhus