On 2-7-2025 21:56, Gina P. Banyard wrote:
Hello internals,
It is this time of year again where we proposed a list of deprecations to add
in PHP 8.5:
https://wiki.php.net/rfc/deprecations_php_8_5
As a reminder, this list has been compiled over the course of the past year by
various different people.
And as usual, each deprecation will be voted in isolation.
We still have a bit of time buffer, so if anyone else has any suggestions, they
are free to add them to the RFC.
Some should be non-controversial, others a bit more.
If such, they might warrant their own dedicated RFC, or be dropped from the
proposal altogether.
Best regards,
Gina P. Banyard
Just leaving a note here that I find it inconceivable that the fast
majority of proposed deprecation (again) do NOT have an impact analysis.
I've spoken up about this before and will continue to do this as it
basically means a "blind vote", where voters can only rely on their own
experience to gauge the impact and I expect the majority of voters to
predominantly work on code which already follows a lot of best
practices, which skews the vote towards deprecation, disregarding the
real world impact on less clean codebases.
As for the proposed deprecations themselves (aside from the fact that
the sheer number of proposed deprecations is quite staggering, but
that's been mentioned before), I'm just leaving some opinion here for
voters to chew on:
== Deprecate semicolon after case in switch statement ==
Opinion: Feels like an unnecessary deprecation.
Side-note: The deprecation is also already flagged by PHPCS and will be
auto-fixable as of PHP_CodeSniffer 3.13.3 (via the
PSR2.ControlStructures.SwitchDeclaration sniff).
== Deprecate attributes applying to multiple class properties/constants ==
Opinion: while multi-constant and multi-property declarations are not
all that common (as PSR-2 forbids them), they are supported in PHP, so I
don't see why it would be necessary to make them second-class citizens
with this deprecation.
Next you won't be able to type multi-constant and multi-property
declarations.... this feels like a wrong turn.
== Deprecate backticks as an alias for shell_exec ==
Opinion: Feels like an unnecessary deprecation unless another purpose
for the backtick operator is already planned, in which case, please
mention it.
== Deprecate the __sleep() and __wakeup() magic methods ==
Opinion: I foresee this deprecation being problematic for code which
needs to support a wider range of PHP versions than just the latest and
greatest. These are often used to block (un)serialization for security
reasons.
== Deprecate using values null as an array offset and when calling
array_key_exists() ==
Opinion: I fear this will just lead to people blindly adding type casts
instead of the code being properly fixed.
== Deprecate Reflection*::setAccessible() ==
Opinion: will probably cause quite a lot of busy-work/code churn, but I
also see the point of adding the deprecation notice.
== Deprecate ReflectionProperty::getDefaultValue() for properties
without default values ==
Opinion: I expect this will cause busy-work again, for little real world
gain.
== Deprecate passing spl_autoload_call() to spl_autoload_unregister() ==
Opinion: I'm willing to bet there is at least one codebase doing this
deliberately to remove all autoloading callbacks. Having said, the
alternative seems reasonable enough.
== Deprecate non-canonical type names for settype() ==
I seem to remember seeing mention of this deprecation proposal being
withdrawn, but it's still in the RFC ?
Opinion: I foresee problems with this deprecation as the `gettype()`
method returns the long values, so it would break any code which uses
some combination of `settype()` and `gettype()`.
== Deprecate FILTER_DEFAULT constant ==
Opinion: I expect this may have a higher impact than anticipated. I also
wonder if the deprecation notice shouldn't mention/suggest using a
proper filter instead ?
== Make $filter parameter mandatory for filter_*() functions ==
Opinion: makes sense, but I expect this will yield quite some busy work
again.
== Deprecate no-op functions from the resource to object conversion ==
Opinion: makes sense as a follow-up, but will cause yet more busy work
to add the `@` operator everywhere these functions are used in PHP code
supporting a wide range of PHP versions.
---
The other deprecations either make sense to me or I have no opinion on them.
Smile,
Juliette
