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
