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
https://news-web.php.net/php.internals/129189.
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:
https://github.com/php/policies/blob/main/release-process.rst#backward-compatibility.
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:
https://news-web.php.net/php.internals/129202.
Best regards
Tim Düsterhus
