Hi
Am 2026-06-24 17:29, schrieb Rowan Tommins [IMSoP]:
It is insofar relevant that deprecations have zero immediate impact.
There might be an impact once the actual removal happens, but users
have at least 4 years until the PHP version that first made them aware
that something is deprecated goes out of (security) support and they
might be required to upgrade to a PHP version where the deprecated
functionality changed or was removed.
I hate this argument.
Unless otherwise stated, a proposal to deprecate something is a
proposal to remove / forbid it in future. The impact analysis being
asked for is the impact of that removal / prohibition.
Two years for PHP 8.4 we also had proposals that explicitly specified
that no removal was planned for now, that removal would be left to a
separate vote and explicit promises about when the removal may happen at
the earliest (uniqid and md5/sha1). Back then “just deprecation, no
removal” was considered to be an unacceptable impact in discussion and
the proposal was ultimately declined.
The deprecation period also allows us to obtain *at least* one year of
data before the version that does the removal would be released. If it
turns out that we missed something during the proposal - e.g. by issues
being filed in the tracker, the deprecation can still be reversed and
the functionality not actually changed or removed. One example would be
the deprecation of __sleep() last year and I seem to remember that
someone mentioned before that another deprecation that already shipped
also wasn't followed through with a removal and instead be reverted.
Bias is inevitable: listing the benefits of changing something without
any mention of its impact on existing code is also bias. To knowingly
omit information that might weaken your case would be dishonest.
If you think the raw numbers don't tell the whole story, it's up to you
to explain why. When I proposed to deprecate utf8_encode/decode, I
looked into every single usage I could find, so I could make the case
that it was used wrong more often than right. Most removals don't need
that level of detail, because often some easy numbers *do* tell a clear
story.
I believe that raw numbers don't tell a correct story for *any* of the
proposals and fundamentally can't. Any kind of impact analysis performed
by the RFC authors can naturally only account for public code (and their
own code) and an analysis on Packagist packages, as usually done,
completely disregards anything that is not published on Packagist. An
example of the latter would be many applications that while relying on
Packagist for their dependencies are not themselves published on
Packagist. An analysis on the top X Packagist packages will further be
biased towards the big frameworks, which from my experience will have
the least trouble to adjust for deprecations. And then of course some
proposals are not (practically) analyzable with (naive) static analysis
alone, since they will require pulling the entire dependency tree for
each package to get the full type information from dependencies. And
others require code to already be in a good shape to be analyzable
properly, which based on my experience likely is code that has already
identified the functionality that is proposed for deprecation as
problematic and is thus not affected at all.
Given the above, I feel that you might as well roll a dice to come up
with a number that would be equally likely to represent the actual
situation.
Is there some specific proposal where you feel there is a stark
mismatch between the cost for existing code and the benefit in making
the language easier to learn
How can anyone answer that question without some information about the
cost for existing code? Are you saying that every voter should perform
their own research on every proposal?
We have a diverse set of voters, many of them with multi-year experience
with PHP, Open Source, different employers or clients in case of
agencies. I believe that they will be capable of judging the impact
appropriately. I've already mentioned how I believe the cost-benefit
ratio for `metaphone()` is not good - and you did the same for `_()`. I
would agree on your assessment regarding `_()` and will ask Gina to
split the deprecation of `_` (the constant) from `_()` (the function)
into separate votes.
Best regards
Tim Düsterhus
