On 22-6-2026 22:54, Tim Düsterhus wrote:
Hi
On 6/22/26 17:58, Juliette Reinders Folmer wrote:
Unfortunately none of the proposals contain a proper impact analysis.
Unless your definition of “proper” differs from mine, this is false.
As an example, the “Deprecate using "let" as an identifier”
deprecation proposal contains this paragraph:
The analysis performed at part of the let construct (Block Scoping)
RFC indicated an insignificant usage of “let” in the wild.
which is more than “none of the proposals”. The same is true for
“Deprecate returning from a finally block” proposal.
But as every year:
- Harmful functionality does not become less harmful, just because it
is widely used.
- Deprecations are not a breaking change. This is even explicitly
written down in the PHP project’s policy as of the
https://wiki.php.net/rfc/policy-release-process-update RFC.
A majority of the deprecation messages provide actionable advice to
the user, and all of the proposals have a proper justification - even
if you might personally disagree with it. As an example, I don't
personally agree with the deprecation of metaphone(), see
https://news-web.php.net/php.internals/130806.
Tim, please don't try to gaslight me.
The fact that one out of twentyfive proposals has some vague statement
about the impact, without any details of what was analysed or how,
without definition of "insignificant", and without a link to details
giving credibility to that statement, only goes to highlight that these
proposals lack a proper impact analysis.
I agree though that the "finally block" proposal is the only positive
exception to this.
Other than that, I did not express an opinion on the details of the
individual proposals, but (as every year) you seem to draw conclusions
based on things I never said.
The fact that you even feel the need to point out that "deprecations are
not a breaking change" is extremely offensive in and of itself. You
should know better.
Please don't do that.
Smile,
Juliette
