Hi Juliette,
For the mb_strimwidth() proposal an impact analysis is provided at the end
("over 100 projects were reviewed").
For the other proposals there isn't and we do not believe this to be
useful. We consider deprecations to be different from other RFCs that add
new features,
because functionality usually is deprecated because it is "harmful" in one
way or another. A large impact (i.e. broad usage) should not necessarily be
an
argument against deprecation. Please also keep in mind that a deprecation
is just that, a deprecation. It gives developers a heads up to migrate off
the
functionality at their own pace. We know that package maintainers are
bugged by users whenever a new deprecation message emerges in a new PHP
version,
but this doesn't mean maintainers must react right away.
Let us elaborate why we don't think impact analysis is needed here:
* As per the TYPE_CURRENCY constant is (a) completely non-functional and
(b) unfixable. As such any code that uses the constant is already broken and
the deprecation is just pointing this out, making the user aware.
* The CRYPT_* constants are possibly the least harmful part of the RFC, but
they still can be misleading to a new developer. They are trivially
polyfilled and
also trivially removed from existing code by replacing them with 1.
* MT_RAND_PHP is broken, because the sequences are not well-defined,
defeating any reason for seeding. More reasons are already given in the RFC.
* mt_rand() is everywhere and we don't believe anyone is denying that fact.
But this should not be a reason against deprecation. As the RFC outlines,
it is trivial to find this function misused with GitHub's search. We
believe that the depreciation benefit outweighs the costs for existing
users.
* ldap_connect() is already soft-deprecated in the documentation.
Regards,
The authors of th RFC
