Hi Jonathan, > It seems the protected but not private destructors idea was already > implemented for PHP 7 (https://3v4l.org/6DFGp) but fell victim to a > regression in 7.3.15/7.4.3 and no-one noticed because it was never added > to the changelog in the first place.
Apparently the engine can successfully call non-public destructors when in the right scope: https://3v4l.org/FEV2fT. This is intentional behavior, as we have explicit visibility checks in the code that calls destructors, and tests for this. This was implemented in the 5.0 development period at the same time as other work on magic method visibility, so my interpretation is that it was likely done purely for consistency. What changed in 7.3.15 is that local variables are now destroyed _after_ popping the current stack frame, which affects the scope in which the object is destroyed in your snippet. This is similar to __construct() and __clone() (whose visibility is used to restrict who can perform the related operation), except that the visibility of __destruct() doesn't really prevent the operation from being performed: the object is still freed after the engine failed to call the destructor. I'm not aware of use-cases for this. Also it would be unreliable as the timing of destructor calls is not always obvious or predictable. Although the current behavior doesn't seem useful, the proposed changes would only address the problem for destructors: We can not apply the same trick to __construct() and __clone(). Best Regards, Arnaud
