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
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
For the DB-specific PDO constants, am I correct that all of those constants and methods already have equivalents in their respective driver classes? (If so, please state that explicitly.)
Everything else seems reasonable to me at the moment.
--Larry Garfield
For the DB-specific PDO constants, am I correct that all of those constants and methods already have equivalents in their respective driver classes? (If so, please state that explicitly.)
I have added the corresponding constant/method.
Best regards,
Gina P. Banyard
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
Thanks for reminding me I should dust off my proposal for cleaning up
ODBC driver support. Might be a good idea to put it to a vote...
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
Thanks for reminding me I should dust off my proposal for cleaning up
ODBC driver support. Might be a good idea to put it to a vote...
Feel free to write a blurb to explain the rationale and add it to the RFC! :)
Best regards,
Gina P. Banyard
Thanks for reminding me I should dust off my proposal for cleaning up
ODBC driver support. Might be a good idea to put it to a vote...Feel free to write a blurb to explain the rationale and add it to the RFC! :)
Best regards,
Gina P. Banyard
Sure, I'll add it!
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
PDO::ERRMODE_WARNING
I am ok with deprecating this mode as I cannot imagine why would anyone use
it. However, can I suggest that we deprecate the silent mode too? How
useful is the silent mode in PDO?
ext/filter deprecations
As much as I hate this extension, I don't think deprecating these functions
is the right choice. It's not unheard of for someone to use filter_input
without the filter parameter to avoid getting the warning on missing value.
See the top comment on
https://www.php.net/manual/en/function.filter-input.php#115086
Maybe we should just unbundle that whole extension?
docref_root
Can this still be used for development environment in another language?
I.e. point to the manual in localized version?
Deprecate using values of type null and bool as array offsets
I can see the value in getting rid of it, but this behavior can be useful
too. For example
$tally[isEnabled($name)]++;
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.ext/filter deprecations
As much as I hate this extension, I don't think deprecating these
functions is the right choice. It's not unheard of for someone to use
filter_input without the filter parameter to avoid getting the warning
on missing value. See the top comment on
https://www.php.net/manual/en/function.filter-input.php#115086Maybe we should just unbundle that whole extension?
Certainly not. It has been the recommended way of accepting incoming
request variables since whenever we removed magic quotes.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
Hello internals,
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 skimming and saw
Deprecate using values of type null and bool as array offsets and
when callingarray_key_exists()
The discussion that follows says what is wrong with null (and I agree
with that), but not why bool should be deprecated as well (in fact it
mentions that bool gets cast to int).
It's just that I've more than once found it self-documenting to use a
bool as an array offset because I wanted to partition an array into two
according to a predicate - e.g., $partition[true] contains those
elements that satisfy the predicate. Especially when the question of
which of those two partitions I want is itself a runtime boolean decision.
Deprecate using values of type null and bool as array offsets and
when callingarray_key_exists()
Still curious about this. What have you got against
$branch = [false => $fail, true => $pass];
or
$taken = $branch[$test == $match];
?
Hello internals,
It is this time of year again where we proposed a list of deprecations to add in PHP 8.5:
For FILTER_CALLBACK, I can see it being useful in the extended mode of filter_var_array, where a separate filter and options can be defined for each key in the subject array. This allows you to build up a set of filters in advance, using callbacks for advanced cases; or even to recurse into another filter_var_array call on sub-arrays.
I am not a huge fan of the filter extension, but don't see any particular reason to remove this one feature of it.
Rowan Tommins
[IMSoP]
Hi,
Hello internals,
It is this time of year again where we proposed a list of deprecations to
add in PHP 8.5:
Here are few notes on the ones that I don't agree with:
Deprecate backticks as an alias for shell_exec
I think this might be too big BC break that might impact many scripts -
would be good to see also if it impacts OSS projects. I guess it will
impact even more non public code bases.
Deprecate the __sleep() and __wakeup() magic methods
I'm not sure about this one. I don't think it's worth it. It's just an
unnecessary BC break IMHO. I would also consider more ext/standard thing
rather than language.
Deprecate the error_prepend_string and error_append_string INI directives
I think it doesn't have a good enough reason to be deprecated and might be
still used. I don't see any problem with keeping them.
Deprecate the report_memleaks INI directive
I think this should be kept as one might not necessarily have time to fix
it but still need to work reasonably with debug build so it makes sense to
suppress it.
Deprecate the $http_response_header predefined variable
I think it's too early for this. I would prefer to not deprecate it at this
time because alternative is available only from 8.4...
Deprecate
filter_input(),filter_input_array(), andfilter_has_var()
I think those functions might be useful in some cases. I would also like to
see their current usage. The case of modification of super global is not
exactly a usual thing so I wouldn't worry much about it.
Kind regards
Jakub
It is this time of year again where we proposed a list of
deprecations to add in PHP 8.5:Here are few notes on the ones that I don't agree with:
Deprecate backticks as an alias for shell_exec
I think this might be too big BC break that might impact many scripts
- would be good to see also if it impacts OSS projects. I guess it
will impact even more non public code bases.
Indeed, I use this all the time in quick hacky shell scripts in PHP.
Best practise? Definitely not. But it certainly is very useful.
Deprecate the error_prepend_string and error_append_string INI
directivesI think it doesn't have a good enough reason to be deprecated and
might be still used. I don't see any problem with keeping them.
+1
cheers,
Derick
It is this time of year again where we proposed a list of
deprecations to add in PHP 8.5:Here are few notes on the ones that I don't agree with:
Deprecate backticks as an alias for shell_exec
I think this might be too big BC break that might impact many scripts
- would be good to see also if it impacts OSS projects. I guess it
will impact even more non public code bases.Indeed, I use this all the time in quick hacky shell scripts in PHP.
Best practise? Definitely not. But it certainly is very useful.
Is their use for quick hacky scripts worth the cost of reserving a symbol that could be repurposed for something else more generally useful in the future? (Not immediately of course, but eventually.)
--Larry Garfield
It is this time of year again where we proposed a list of
deprecations to add in PHP 8.5:Here are few notes on the ones that I don't agree with:
Deprecate backticks as an alias for shell_exec
I think this might be too big BC break that might impact many scripts
- would be good to see also if it impacts OSS projects. I guess it
will impact even more non public code bases.Indeed, I use this all the time in quick hacky shell scripts in PHP.
Best practise? Definitely not. But it certainly is very useful.Is their use for quick hacky scripts worth the cost of reserving a symbol that could be repurposed for something else more generally useful in the future? (Not immediately of course, but eventually.)
--Larry Garfield
This sounds quite negative to me which it is not in my book, IMHO best to have all three available in PHP, so you would have made the argument for me to keep the symbol.
And thinking:
Symbol reuse could perhaps be possible already today with a prefix.
The backticks operator evaluates to a string (or a primitive that could be represented as a string), which is an interface to build upon. For example a "tagging"-function:
$result = shell`git describe --abbrev=0 --match=dev* --tags dev$ver^`;
function shell($what, ...$not)
: on_return_this_type_is_checked_by_the_script_interpreter
{
(random_int(0, 1))
and throw new Error('To Return Never when it's due');
return rtrim(shell_exec(something_with($what, 'and', $not)));
}
This could also improve the current use, even immediately, and eventually helps to think out of the box.
$name = 'PHP-Parser';
$version = '5.5.0';
$hash = 'sha384-vyGSwY5XXGRpPplN6utmy1kOiFBeqy79G0BRG8CnfT8AvHx7TBb99HFHkUEcXSs3';
$res = cas`https://github.com/nikic/{$name}/archive/v{$version}.tar.gz#sri={$hash}#`;
String is the universal interface.
My educated guess is that I don't need to explain the benefits of template literals over ordinary PHP string literals for Larry, but for those who are curious, this is inspired by EcmaScript and you can try it out in your browser or read on MDN about it. Not saying this should be the same syntax, just going into the pink here. Maybe even recent ${'...'} vs. "{${'...'}}" changes in interpolation opened up some room to come closer.
Now if only those backticks would become an aspect of the tag over the assignment so we could get "get hook semantics" on them at the time of tagged-use:
$untagged = ....;
$result1 = tagRed$untagged;
$result2 = tagBlue$untagged;
hmm... not entirely compatible with the current behaviour I'd guess, but who knows, likely conflicts over conflicts in the LALR parser when we start to tag $variable identifiers.
Just my 2 cents.
-- hakre
Is their use for quick hacky scripts worth the cost of reserving a symbol that could be repurposed for something else more generally useful in the future? (Not immediately of course, but eventually.)
--Larry Garfield
snip
My educated guess is that I don't need to explain the benefits of
template literals over ordinary PHP string literals for Larry, but
for those who are curious, this is inspired by EcmaScript and you can
try it out in your browser or read on MDN about it.
Indeed, that's the sort of future reuse I was thinking of as well. But having this be a template:
$foo = tplSomething $here;
But this run a shell command:
$foo = Something $here;
Strikes me as a security nightmare waiting to happen.
--Larry Garfield
Is their use for quick hacky scripts worth the cost of reserving a
symbol that could be repurposed for something else more generally useful in
the future? (Not immediately of course, but eventually.)--Larry Garfield
snip
My educated guess is that I don't need to explain the benefits of
template literals over ordinary PHP string literals for Larry, but
for those who are curious, this is inspired by EcmaScript and you can
try it out in your browser or read on MDN about it.Indeed, that's the sort of future reuse I was thinking of as well.
Yes, I have hoped, so good to read!
Do you know by chance this has gotten some movement towards that form of
reuse in the past? I'd be interested.
But having this be a template:
$foo = tpl
Something $here;But this run a shell command:
$foo =
Something $here;Strikes me as a security nightmare waiting to happen.
Oh, that was not intended. I need your precise eyes for this, and starring
fearfully at the snakes is certainly not good for that. Sorry!
That suggestion is the migration form. Naturally, this needs to be properly
packaged, you can't tell users that template literals are there and leave
them in the un-tagged form as command substitution. Who would do that
seriously?
Users of command substitution would have the opportunity to convert their
backticks into a predefined, tag-limited form of a template literal. That
is fool-proof, and it can't be conflated.
Therefore, there is no unguarded use of command substitution, this is
inserting into the transition for existing users that are using backticks
as they already do today.
My thought in the margin was that of a birthday present for the 25th of the
backticks and users of the language (the global 50th is in 2029.)
Best
-- hakre
Deprecate the __sleep() and __wakeup() magic methods
I'm not sure about this one. I don't think it's worth it. It's just an
unnecessary BC break IMHO. I would also consider more ext/standard thing
rather than language.
I agree with Jakub here, __sleep and __wakeup are just fine. Yes,
__serialize/__unserialize are better, but breaking (or even planning to
break) existing apps doesn't look worth the change.
Deprecate the $http_response_header predefined variable
I think it's too early for this. I would prefer to not deprecate it at
this time because alternative is available only from 8.4...
I agree also here: having the alternative available in 8.4 is too soon,
especially since the new function cannot be polyfilled.
No strong feelings about the other proposals, I'll read other's comments in
the thread before voting.
Nicolas
Hi everyone
It is this time of year again where we proposed a list of deprecations to add in PHP 8.5:
Thanks for the bulk RFC. Some thoughts.
Deprecate __construct() and __destruct() in interfaces
While __construct() is tied to the new expression (at least unless
instantiated through
ReflectionClass::newInstanceWithoutConstructor()), factories creating
instances from class names may still need to check for constructor
compatibility. This is much easier achieved through an interface than
it is through reflection.
With an interface:
interface I {
public function __construct(string $a, string $b);
}
function some_factory(string $class) {
if (!is_a($class, I::class)) {
throw new InvalidArgumentException();
}
return new $class('foo', 'bar');
}
Without an interface:
function some_factory(string $class) {
$reflection = new ReflectionClass($class);
$constructor = $reflection->getConstructor();
if (!$constructor || !$constructor->isPublic()) {
throw new InvalidArgumentException();
}
$params = $constructor->getParameters();
if (count($params) !== 2
|| $params[0]->getType()->getName() !== 'string'
|| $params[1]->getType()->getName() !== 'string') {
throw new InvalidArgumentException();
}
return $class('foo', ['bar']);
}
This implementation is much more complex, and incorrect in multiple ways.
- We could have more than 2 params, with them being optional.
- We could use variadics, i.e. function __construct(string ...$s),
which is completely valid. - Since parameter types are contravariant, they may be substituted
with union types, mixed, or just completely omitted.
Also note that while LSP for __construct() is not enforced for class
inheritance, it is for interfaces, even across multiple class
hierarchy levels. Maybe there is some issue I'm missing. But if not,
I'm not in favor of deprecating/dropping this feature.
Deprecate using values of type null and bool as array offsets and when calling
array_key_exists()
The introduction section also lists float as a type to be deprecated
in array offsets:
Deprecate using values of type null, bool, and float as array offsets and when calling
array_key_exists()
Floats used as array offsets that lose precision already emit a
warning. Can you confirm that floats used as array offsets that do not
lose precision will not start emitting a deprecation?
Deprecate ReflectionClass::getConstant() for missing constants
I don't have strong opinions on this change. However,
ReflectionProperty::getDefaultValue() suffers from a very similar
issue, except that it returns null rather than false
(https://3v4l.org/G2R3l). It would make sense to avoid more
inconsistencies. For example, ReflectionParameter::getDefaultValue()
does throw if the parameter has no default value.
Deprecate ArrayObject and ArrayIterator with objects
Just to add another issue to the list: It can also change readonly
properties of internal classes that the engine does not expect to ever
change. For example, Enum::$name and Enum::$value. This can break
internal logic assumptions (e.g. hard-coded switch cases to handle
internal enums by name) and cause memory corruption. The same goes for
non-readonly properties guarded with the internal equivalent of
__set().
Deprecate passing
spl_autoload_call()tospl_autoload_unregister()
Is such a check actually useful? We can prevent
spl_autoload_unregister(spl_autoload_call(...)), but we can't prevent
spl_autoload_unregister(fn($c) => spl_autoload_call($c)). It seems
very unlikely for this to happen accidentally, and excluding all
functions that don't make sense to pass is not feasible for obvious
reasons. But I don't care too much.
Ilija
Hi everyone
It is this time of year again where we proposed a list of deprecations
to add in PHP 8.5:Deprecate ReflectionClass::getConstant() for missing constants
I don't have strong opinions on this change. However,
ReflectionProperty::getDefaultValue() suffers from a very similar
issue, except that it returns null rather than false
(https://3v4l.org/G2R3l). It would make sense to avoid more
inconsistencies. For example, ReflectionParameter::getDefaultValue()
does throw if the parameter has no default value.
Good catch, I wasn't aware of this behavior for
ReflectionProperty::getDefaultValue(). I agree that we should avoid such
inconsistencies, and thus have proposed deprecating
ReflectionProperty::getDefaultValue() for properties that have no default
value. See
https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_reflectionpropertygetdefaultvalue_for_properties_without_default_values
-Daniel
Hi
Deprecate passing
spl_autoload_call()tospl_autoload_unregister()Is such a check actually useful? We can prevent
spl_autoload_unregister(spl_autoload_call(...)), but we can't prevent
spl_autoload_unregister(fn($c) => spl_autoload_call($c)). It seems
very unlikely for this to happen accidentally, and excluding all
functions that don't make sense to pass is not feasible for obvious
reasons. But I don't care too much.
See also my reply to Niels. Such a check already exists:
That's an explicit special case in the language that could go away.
Best regards
Tim Düsterhus
Hi everyone
It is this time of year again where we proposed a list of deprecations to add in PHP 8.5:
Thanks for the bulk RFC. Some thoughts.
Deprecate __construct() and __destruct() in interfaces
We agreed with Tim to remove it from this RFC.
We still think __destruct() in interfaces should be deprecated,
but there are other interactions with __destruct() that should be on the chopping board,
so this is punted to later with a comprehensive proposal.
Deprecate using values of type null and bool as array offsets and when calling
array_key_exists()The introduction section also lists float as a type to be deprecated
in array offsets:Deprecate using values of type null, bool, and float as array offsets and when calling
array_key_exists()Floats used as array offsets that lose precision already emit a
warning. Can you confirm that floats used as array offsets that do not
lose precision will not start emitting a deprecation?
Correct, that was a left over from a previous iteration.
This should be fixed now.
Deprecate ArrayObject and ArrayIterator with objects
Just to add another issue to the list: It can also change readonly
properties of internal classes that the engine does not expect to ever
change. For example, Enum::$name and Enum::$value. This can break
internal logic assumptions (e.g. hard-coded switch cases to handle
internal enums by name) and cause memory corruption. The same goes for
non-readonly properties guarded with the internal equivalent of
__set().
Added this as an example
Deprecate passing
spl_autoload_call()tospl_autoload_unregister()Is such a check actually useful? We can prevent
spl_autoload_unregister(spl_autoload_call(...)), but we can't prevent
spl_autoload_unregister(fn($c) => spl_autoload_call($c)). It seemsvery unlikely for this to happen accidentally, and excluding all
functions that don't make sense to pass is not feasible for obvious
reasons. But I don't care too much.
As Tim mentioned, this is not about preventing workarounds but removing the ability to "flush" the autoloading table.
See https://3v4l.org/GVl7Z which showcases that a "proxy" call to spl_autoload_call() does NOT behave the same as passing it directly to the function.
Best regards,
Gina P. Banyard
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.
The changes to filter continue to undermine what the extension was meant
to do. The filter.default INI setting was deprecated in PHP
8.1, which was already a mistake.
The intention behind the filter extension was that admins can set a
default filter for all data coming in through this filter.default
setting as a "safe" fallback. That could/should probably even be a
filter that just makes all data "☺" for example, to indicate you're
working with unsanitised data. (I don't think there is such a filter
though).
This fallback could then be 'circumvented' by using the
filter_input/input_array() functions, so that each of them can employ
its own unique, and useful, filter on that specific element in the
GET/POST/etc arrays.
Saying that "The filter_input() and filter_input_array() functions
operate on the original values provided by the SAPI that populate the
superglobals for $_GET, $_POST, $_SERVER, $_ENV, and $_COOKIE. " is
basically documenting the original intention of these functions.
If there is anything odd with your example, is that you can modify the
values in GET/POST/etc superglobals to begin with.
"As it is easy and straight forward to have the same behaviour by using
filter_var($_GET['a'], /* other params /) and filter_var_array($_GET,
/ other params */), we propose to deprecate filter_input() and
filter_input_array()."
No. The whole point is that these functions read the raw data, the one
that wasn't filtered by the default filter (which has been inadvisably
deprecated).
I would therefore undeprecate filter.default, and allow these filter
functions are they currently are, because they implement the original
design idea behind this extension.
cheers,
Derick
Hi
The intention behind the filter extension was that admins can set a
default filter for all data coming in through thisfilter.default
setting as a "safe" fallback. That could/should probably even be a
Genuine question: Is that intention documented anywhere?
https://www.php.net/manual/en/function.filter-input.php only makes
factual statements about the behavior, but not how one is supposed to
use them. Similarly
https://www.php.net/manual/en/filter.configuration.php also says that a
default filter can be configured, but not why one would want to do so.
Best regards
Tim Düsterhus
The intention behind the filter extension was that admins can set a
default filter for all data coming in through this
filter.defaultsetting as a "safe" fallback. That could/should
probably even be aGenuine question: Is that intention documented anywhere?
https://www.php.net/manual/en/function.filter-input.php only makes
factual statements about the behavior, but not how one is supposed to
use them. Similarly
https://www.php.net/manual/en/filter.configuration.php also says that
a default filter can be configured, but not why one would want to do
so.
I've done a bit of archeology, and came up with the following:
The SAPI API was designed in 2003:
https://github.com/php/php-src/commit/7429c2dc3f72ed9a6a41ccefc68595e76319cdae
The extension started in PECL in 2005, and then was moved into the core
distribution: https://pecl.php.net/package/filter — unfortunately it
seems that the history of the SVN repository was lost.
There is some context in the mailing list archive:
- https://externals.io/message/25728#25738
- https://externals.io/message/43721
- https://news-web.php.net/php.internals/23064
- https://news-web.php.net/php.internals/23627
There is a comment from Rasmus on why filter keeps the raw information
in 2006: https://news-web.php.net/php.pecl.dev/4000
in 2014: https://news-web.php.net/php.internals/74371
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
Hi
The intention behind the filter extension was that admins can set a
default filter for all data coming in through thisfilter.default
setting as a "safe" fallback. That could/should probably even be aGenuine question: Is that intention documented anywhere? https://www.php.net/manual/en/function.filter-input.php only makes factual statements about the behavior, but not how one is supposed to use them. Similarly https://www.php.net/manual/en/filter.configuration.php also says that a default filter can be configured, but not why one would want to do so.
If we look into php-src docs, nowadays under the docs-old entry IIRC, we may find how to write a filter.
That it is on the level of extending PHP, and I'd interpret that it strongly points towards system administration or at least that it is about making systematic use of the PHP filter extension.
Have not yet made research based on age or reviewed specifically after your message, e.g. correlations towards the date since ext.filter is part of the solution, but my nose tells me the documentation is likely related to what you'd like learn more about.
This may be totally misleading, but when I combine that with Derricks expertise in php-src and his earlier comment, I'm somehow under the impression this has the potential to answer even genuine questions that require to reason about documented intend.
So please let me know if it is still of help @Tim
-- hakre
The intention behind the filter extension was that admins can set a
default filter for all data coming in through thisfilter.default
setting as a "safe" fallback. That could/should probably even be a
filter that just makes all data "☺" for example, to indicate you're
working with unsanitised data. (I don't think there is such a filter
though).
Perhaps the option should be something like "filter.mandatory=1", blanking or poisoning the superglobals and obliging users to go through filter_var?
Rowan Tommins
[IMSoP]
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.The changes to filter continue to undermine what the extension was meant
to do. The filter.default INI setting was deprecated in PHP
8.1, which was already a mistake.
The reason that INI setting was deprecated was because it was effectively resurrecting magic quotes, and even weirder combinations.
So no, it was deprecated for a good reason, but if you care so much about this, feel free to raise an RFC to undeprecate it.
The intention behind the filter extension was that admins can set a
default filter for all data coming in through thisfilter.default
setting as a "safe" fallback. That could/should probably even be a
filter that just makes all data "☺" for example, to indicate you're
working with unsanitised data. (I don't think there is such a filter
though).This fallback could then be 'circumvented' by using the
filter_input/input_array() functions, so that each of them can employ
its own unique, and useful, filter on that specific element in the
GET/POST/etc arrays.Saying that "The
filter_input()andfilter_input_array()functions
operate on the original values provided by the SAPI that populate the
superglobals for $_GET, $_POST, $_SERVER, $_ENV, and $_COOKIE. " is
basically documenting the original intention of these functions.
In such case, we should provide sapi_X() functions that allow to query the raw values even without the filter extension.
Regardless, I have removed the functions from the RFC as multiple people find use in them.
If there is anything odd with your example, is that you can modify the
values in GET/POST/etc superglobals to begin with.
This is core PHP behaviour, if you want to propose making those values read only, I would be in favour.
"As it is easy and straight forward to have the same behaviour by using
filter_var($_GET['a'], /* other params /) and filter_var_array($_GET,
/ other params */), we propose to deprecatefilter_input()and
filter_input_array()."No. The whole point is that these functions read the raw data, the one
that wasn't filtered by the default filter (which has been inadvisably
deprecated).I would therefore undeprecate filter.default, and allow these filter
functions are they currently are, because they implement the original
design idea behind this extension.cheers,
Derick
Again I disagree that the INI setting should be undeprecated as stated above.
Moreover, I would love to know what the original design idea of this extension is and why was this never documented.
Because the documentation was in a horrendous state before I tried improving it last winter, and the extension is also in a state filled with bugs and XFAILed tests.
Best regards,
Gina P. Banyard
Hello internals,
It is this time of year again where we proposed a list of deprecations to
add in PHP 8.5:
Looking at it again I think this huge deprecation RFC is not the right
approach. I'm not sure what are we trying to do here but I was just
checking how many deprecation had few previous versions and
PHP-8.3 - 5 deprecations - https://wiki.php.net/rfc/deprecations_php_8_3
PHP-8.4 - 22 deprecations - https://wiki.php.net/rfc/deprecations_php_8_4
And this one is 46. I know that there were few independent RFC's but that's
a huge increase anyway and I'm not really sure it's a good idea to do that
many in a single release.
It is also not convenient for discussion in a single thread which we can be
seen already. I'm not saying there should be an RFC for each deprecation
but maybe having at least RFC for each section would be better as it would
allow properly consider each of those depredations. Or somehow split to
some logical chunks...
Kind regards,
Jakub
Hi
First of all, that's a huge list of deprecations and I think we should tone down on that.
Especially if a feature still has a purpose and is not harmful or buggy, then we should probably consider not deprecating it.
Secondly, I'm tired of having to deal with useless deprecation messages.
A lot of deprecation messages are completely useless for developers because they do not point to a reason or a replacement.
That leaves you needing to look up the documentation, which is also incomplete.
See https://github.com/php/php-src/issues/14320
Therefore, any deprecation proposed in this RFC that does not explicitly list the deprecation message, I will vote no for.
There are some things in the list I don't care about or I don't have a lot of insight of its uses in, and I will abstain for voting on them.
There are a few things I will vote no for:
-
Deprecate semicolon after case in switch statement.
People seem to use this and it doesn't seem harmful to have. Just because you don't like it doesn't mean we should yeet it. -
Deprecate attributes applying to multiple class properties/constants.
On the edge, confusing yes, but it might break real code. -
Deprecate using values of type null and bool as array offsets and when calling
array_key_exists()
Deprecating this would make the language more inconsistent by allowing this on array offsets but not on the function. -
Deprecate __debugInfo() returning null
Weird, especially as the docs say the return type is ": array", but not harmful. -
Deprecate ReflectionParameter::allowsNull()
This shorthand doesn't hurt anybody, and is convenient, I don't see the point in deprecating it. -
Deprecate passing
spl_autoload_call()tospl_autoload_unregister()
This is very ad hoc, and as Ilija pointed out, we can't prevent workarounds for this. So what's the point really.
The behaviour may be weird, but notice that people won't do this by accident. -
Deprecate passing null to
readdir(),rewinddir(), andclosedir()
Dubious but not really harmful I think. -
Based on Derick's comments I will vote no on the ext/filter deprecations. I was already going to vote no on the filter_* functions though.
-
Deprecate driver specific PDO constants and methods
Too early.
Kind regards
Niels
Hi
First of all, that's a huge list of deprecations and I think we should tone down on that.
Especially if a feature still has a purpose and is not harmful or buggy, then we should probably consider not deprecating it.
It's a long list, but many of the deprecations are just obvious
follow-ups of a previous RFC or closely related.
As an example, I would consider all the _close() / _free() /
destroy() function deprecations to be a single one in practice and
then one that just fixes an inconsistency, since others are already
deprecated. Similarly Reflection*::setAccessible() is a follow-up for a
previous RFC that deferred the deprecation to reduce the impact on
existing code.
Defining "harmful" is also complicated. Is making the language harder to
learn for newcomers "harmful" (e.g. the case-with-semicolon one, which
is just a tiny bit of syntax difference for the same thing)? Is allowing
for confusing code (e.g. Reflection::setAccessible(false)) "harmful"?
In both cases, I'd say: Yes, that is harmful.
Secondly, I'm tired of having to deal with useless deprecation messages.
A lot of deprecation messages are completely useless for developers because they do not point to a reason or a replacement.
That leaves you needing to look up the documentation, which is also incomplete.
See https://github.com/php/php-src/issues/14320
Therefore, any deprecation proposed in this RFC that does not explicitly list the deprecation message, I will vote no for.
I agree that having useful deprecation messages is important and I've
just added a trigger_error() example to the PDO 'uri:' deprecation
that I proposed. My other proposals already had the #[\Deprecated]
attribute including the message.
There are a few things I will vote no for:
- Deprecate semicolon after case in switch statement.
People seem to use this and it doesn't seem harmful to have. Just because you don't like it doesn't mean we should yeet it.
See above. Also: The RFC seems to indicate that this is not actually
used in practice.
- Deprecate attributes applying to multiple class properties/constants.
On the edge, confusing yes, but it might break real code.
Since this is a recurring thing, I feel compelled to point out
terminology: A deprecation in itself is not a breaking change.
- Deprecate __debugInfo() returning null
Weird, especially as the docs say the return type is ": array", but not harmful.
I consider undocumented behavior to be harmful and in this case
deprecating (and removing) the undocumented behavior seems to be better
than adding another special case to the language that users need to
learn about.
- Deprecate passing
spl_autoload_call()tospl_autoload_unregister()
This is very ad hoc, and as Ilija pointed out, we can't prevent workarounds for this. So what's the point really.
The behaviour may be weird, but notice that people won't do this by accident.
See above regarding "undocumented behavior". Also to my understanding
this is not about "preventing workarounds", but rather removing this
branch, which is just surprising behavior:
Best regards
Tim Düsterhus
Hey Tim,
Hi
Since this is a recurring thing, I feel compelled to point out
terminology: A deprecation in itself is not a breaking change.
Let me disagree with this. Yes, a deprecation in itself doesn't break
running code. However it is both a) an annoyance (you want to get rid of
deprecations) and b) a promise that it will be eventually broken.
So, it requires a code change, maybe not immediately, but it will. And
that's what we're getting at. It will break real code, just not right now.
And there's not always a point in breaking real code for the sake of
"this might be potentially confusing".
(And for the feature in question, I do disagree that it's confusing, but
that's not the point of this mail.)
Bob
Hi
Let me disagree with this. Yes, a deprecation in itself doesn't break
running code. However it is both a) an annoyance (you want to get rid of
deprecations) and b) a promise that it will be eventually broken.
Yes, I understand that a deprecation usually leads to a removal.
Nevertheless I found it important to point out that the deprecation
itself is not a breaking change, since it is a common theme that folks
incorrectly claim that "PHP X.Y broke my code", when it's just some
deprecation messages being emitted. The deprecation allows you to fix
the issue at hand at a pace you are comfortable with. As an example, if
the code in question is in the process of being replaced anyways, then
you don't need to do anything.
From my personal anecdata: I'm fixing deprecations right away and the
only painful one I'm remembering in the recent years is
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg. For this
iteration, I'm likewise expecting most of them to be easily handled with
the existing tooling (IDEs, Code formatters, …).
Also, even for PHP 8.4, where the proposed deprecation of uniqid()
(and others) specifically said that there are no plans for removal
(https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_uniqid), folks
considered the deprecation warning alone to be an inacceptable breaking
change.
And there's not always a point in breaking real code for the sake of
"this might be potentially confusing".
Yes, the amount of possible confusion certainly needs to be weighted
against the amount of usage. As a rule of thumb, I'd claim that the more
commonly a specific syntax is used, the less confusing it becomes, since
there are more references in the wild for folks to come across.
Best regards
Tim Düsterhus
Nevertheless I found it important to point out that the deprecation
itself is not a breaking change, since it is a common theme that folks
incorrectly claim that "PHP X.Y broke my code", when it's just some
deprecation messages being emitted. The deprecation allows you to fix
the issue at hand at a pace you are comfortable with. As an example, if
the code in question is in the process of being replaced anyways, then
you don't need to do anything.
The RFC at hand states:
| The RFC proposes to deprecate the listed functionality in PHP 8.5 and
| remove it in PHP 9 (except where otherwise noted).
That might give users only a year to fix the deprecated features, what
might not match everybody's pace, though.
It seems to be prudent to reduce the number of deprecations for the
ultimate (and maybe the penultimate) minor version prior to a major
release. Of course, that would require us to plan ahead. :|
Christoph M. Becker
Hi
Am 2025-07-09 12:34, schrieb Christoph M. Becker:
The RFC at hand states:
| The RFC proposes to deprecate the listed functionality in PHP 8.5 and
| remove it in PHP 9 (except where otherwise noted).That might give users only a year to fix the deprecated features,
what
might not match everybody's pace, though.
Each PHP version is supported for 4 years by the PHP project [1], thus
giving folks at least 4 years to handle each deprecation until they are
forced to upgrade to a supported PHP version.
Best regards
Tim Düsterhus
[1] And possibly even longer by the various Linux distributions out
there. As an example PHP 7.4 is still supported by Debian in the
oldstable Bullseye branch and got its last update on 2025-03-19:
https://tracker.debian.org/news/1630059/accepted-php74-7433-1deb11u8-source-into-oldstable-security/
Am 2025-07-09 12:34, schrieb Christoph M. Becker:
That might give users only a year to fix the deprecated features, what
might not match everybody's pace, though.Each PHP version is supported for 4 years by the PHP project [1], thus
giving folks at least 4 years to handle each deprecation until they are
forced to upgrade to a supported PHP version.
That point is moot for a lot of software where the developers are not
necessarily in control of which PHP version is used (e.g. WordPress).
Cheers,
Christoph
Hi
Am 2025-07-10 15:00, schrieb Christoph M. Becker:
Each PHP version is supported for 4 years by the PHP project [1], thus
giving folks at least 4 years to handle each deprecation until they
are
forced to upgrade to a supported PHP version.That point is moot for a lot of software where the developers are not
necessarily in control of which PHP version is used (e.g. WordPress).
In practice this kind of software already needs to check the PHP version
and newer PHP versions need to be allow-listed, since newer PHP versions
might introduce breaking changes that do not go through the deprecation
process (some of them might not even be considered a breaking change,
e.g. the introduction of a new class or function). This kind of breaking
change would provide even less of a “heads up” compared to a
Deprecation. One of those that affected myself was
https://wiki.php.net/rfc/static_variable_inheritance.
Best regards
Tim Düsterhus
Hey,
Hi
First of all, that's a huge list of deprecations and I think we should tone down on that.
Especially if a feature still has a purpose and is not harmful or buggy, then we should probably consider not deprecating it.
Yeah, I agree. The list of deprecations is too big and possibly should
be multiple RFCs. Let's keep it in mind for next year at least, please.
Deprecating should be a selective process, just like adding features is.
I don't think we really have big RFCs which simply add a bunch of
unrelated stuff.
Secondly, I'm tired of having to deal with useless deprecation messages.
A lot of deprecation messages are completely useless for developers because they do not point to a reason or a replacement.
That leaves you needing to look up the documentation, which is also incomplete.
Seehttps://github.com/php/php-src/issues/14320
Therefore, any deprecation proposed in this RFC that does not explicitly list the deprecation message, I will vote no for.
Good idea. I can support that.
There are some things in the list I don't care about or I don't have a lot of insight of its uses in, and I will abstain for voting on them.There are a few things I will vote no for:
Deprecate semicolon after case in switch statement.
People seem to use this and it doesn't seem harmful to have. Just because you don't like it doesn't mean we should yeet it.Deprecate attributes applying to multiple class properties/constants.
On the edge, confusing yes, but it might break real code.Deprecate using values of type null and bool as array offsets and when calling
array_key_exists()
Deprecating this would make the language more inconsistent by allowing this on array offsets but not on the function.Deprecate __debugInfo() returning null
Weird, especially as the docs say the return type is ": array", but not harmful.Deprecate ReflectionParameter::allowsNull()
This shorthand doesn't hurt anybody, and is convenient, I don't see the point in deprecating it.Deprecate passing
spl_autoload_call()tospl_autoload_unregister()
This is very ad hoc, and as Ilija pointed out, we can't prevent workarounds for this. So what's the point really.
The behaviour may be weird, but notice that people won't do this by accident.
That one is probably just getting rid of the special casing in the code,
which I'd support.Deprecate passing null to
readdir(),rewinddir(), andclosedir()
Dubious but not really harmful I think.Based on Derick's comments I will vote no on the ext/filter deprecations. I was already going to vote no on the filter_* functions though.
Deprecate driver specific PDO constants and methods
Too early.Kind regards
Niels
To add to Niels list:
-
Deprecate passing string which are not one byte long to
ord()
This behaviour is consistent withmb_ord()as well. If we deprecate
one, we also should deprecate the other. But that makes no sense,
because the latter is not fixed with. So let's just not deprecate either. -
Some INI deprecations:
** Deprecate the docref_root and docref_ext INI directives
What's the point? Why do these need to be deprecated? If these are
not set you do not get clickable links at all, unrelated to mirrors and
such.
** Deprecate the error_prepend_string and error_append_string INI directives
Why is that of questionable use? Why is "this is a development and
debugging feature" considered a valid reason to get rid of something? It
allows prominently displaying issues in development when they would be
hidden behind other HTML otherwise.
** Deprecate the report_memleaks INI directive
So, "I'm currently working with this code having a known memory leak
and I want to suppress it" is not a valid reason? If you select that
that's a very deliberate opt-in.
Bob
** Deprecate the error_prepend_string and error_append_string INI directives
Why is that of questionable use? Why is "this is a development and debugging feature" considered a valid reason to get rid of something? It allows prominently displaying issues in development when they would be hidden behind other HTML otherwise.
I recently made a change to the php_error_cb function for the Error
Backtraces v2 RFC (https://wiki.php.net/rfc/error_backtraces_v2), and
I recall that working inside that function was quite difficult. The
error_prepend_string and error_append_string directives are a tiny
part of the complexity there, but nonetheless removing them would
maybe start to move us in a direction of greatly simplifying the
implementation of php_error_cb, which I would support. I don't have
strong feelings here, however.
** Deprecate the error_prepend_string and error_append_string INI directives
Why is that of questionable use? Why is "this is a development and debugging feature" considered a valid reason to get rid of something? It allows prominently displaying issues in development when they would be hidden behind other HTML otherwise.I recently made a change to the php_error_cb function for the Error
Backtraces v2 RFC (https://wiki.php.net/rfc/error_backtraces_v2), and
I recall that working inside that function was quite difficult. The
error_prepend_string and error_append_string directives are a tiny
part of the complexity there, but nonetheless removing them would
maybe start to move us in a direction of greatly simplifying the
implementation of php_error_cb, which I would support. I don't have
strong feelings here, however.
I removed it as it seems my justification was not enough,
if you still think it would be worthwhile by expanding on this complexity, that would be great!
I do know aswell that any call to zend_error() doesn't use the docref IIRC, which leads to very inconsistent styling.
Best regards,
Gina P. Banyard
Hi
First of all, that's a huge list of deprecations and I think we should tone down on that.
Especially if a feature still has a purpose and is not harmful or buggy, then we should probably consider not deprecating it.
The list of deprecation being "huge" is a consequence of more people working on php-src.
We previously also had "large" deprecation RFCs like the one for 8.1, with some deprecations dropped.
See: https://wiki.php.net/rfc/deprecations_php_8_1
Moreover, "harmful" is very much in the eyes of the beholder.
Secondly, I'm tired of having to deal with useless deprecation messages.
A lot of deprecation messages are completely useless for developers because they do not point to a reason or a replacement.
That leaves you needing to look up the documentation, which is also incomplete.
See https://github.com/php/php-src/issues/14320
Therefore, any deprecation proposed in this RFC that does not explicitly list the deprecation message, I will vote no for.
I have added the deprecations messages for my own proposals,
but I don't see this as a valid reason to vote against one.
The deprecation message is very much an implementation detail, and we should be able to improve it at any point.
This is also much easier now that we can use the #[Deprecated] attributes on the majority of internals symbols, as that was one of the major limitations.
There are some things in the list I don't care about or I don't have a lot of insight of its uses in, and I will abstain for voting on them.
There are a few things I will vote no for:
[...]
- Deprecate using values of type null and bool as array offsets and when calling
array_key_exists()
Deprecating this would make the language more inconsistent by allowing this on array offsets but not on the function.
I am slightly confused by what you mean by "allowing this on array offsets but not on the function".
However, null is not accepted by functions that accept scalar types, and bool would neither if my other RFC is approved.
Moreover, a type declaration of int|string accepted Stringable objects, however array offsets do not accept objects at all.
- Deprecate _debugInfo() returning null
Weird, especially as the docs say the return type is ": array", but not harmful.
Again, harmful here is very subjective.
But as this is not my proposal, I will not comment further on it.
[...]
- Deprecate passing
spl_autoload_call()tospl_autoload_unregister()
This is very ad hoc, and as Ilija pointed out, we can't prevent workarounds for this. So what's the point really.
The behaviour may be weird, but notice that people won't do this by accident.
As replied to Ilija, and as Tim already mentioned, the workaround do NOT behave the same way as passing the function directly.
- Deprecate passing null to
readdir(),rewinddir(), andclosedir()
Dubious but not really harmful I think.
I disagree that relying on implicit global state is not harmful.
- Based on Derick's comments I will vote no on the ext/filter deprecations. I was already going to vote no on the filter* functions though.
I have removed the functions anyway, however FILTER_DEFAULT is an incredibly problematic name, and not passing a filter is also problematic, so those remain on the RFC.
- Deprecate driver specific PDO constants and methods
Too early.
I disagree with too early as the migrations for the constants is extremely easy and can be done by tools like Rector (or hell even sed if you feel adventurous)
and the methods are effectively a hack on the PDO class which is already weird enough.
Best regards,
Gina P. Banyard
Secondly, I'm tired of having to deal with useless deprecation messages.
A lot of deprecation messages are completely useless for developers because they do not point to a reason or a replacement.
That leaves you needing to look up the documentation, which is also incomplete.
See https://github.com/php/php-src/issues/14320
Therefore, any deprecation proposed in this RFC that does not explicitly list the deprecation message, I will vote no for.I have added the deprecations messages for my own proposals,
Thanks!
but I don't see this as a valid reason to vote against one.
The deprecation message is very much an implementation detail, and we should be able to improve it at any point.
True, and I have voted against things before due to implementation details.
There are some things in the list I don't care about or I don't have a lot of insight of its uses in, and I will abstain for voting on them.
There are a few things I will vote no for:
[...]
- Deprecate using values of type null and bool as array offsets and when calling
array_key_exists()
Deprecating this would make the language more inconsistent by allowing this on array offsets but not on the function.I am slightly confused by what you mean by "allowing this on array offsets but not on the function".
However, null is not accepted by functions that accept scalar types, and bool would neither if my other RFC is approved.
Moreover, a type declaration of int|string accepted Stringable objects, however array offsets do not accept objects at all.
I'll clarify:
You're allowed to do $array[null], $array[3.14], etc... and the key will coerce.
I expect array_key_exists() to behave the same way as keys on array accesses do.
- Deprecate passing
spl_autoload_call()tospl_autoload_unregister()
This is very ad hoc, and as Ilija pointed out, we can't prevent workarounds for this. So what's the point really.
The behaviour may be weird, but notice that people won't do this by accident.As replied to Ilija, and as Tim already mentioned, the workaround do NOT behave the same way as passing the function directly.
Yeah, I misunderstood this.
Kind regards
Niels
There are a few things I will vote no for:
[...]
- Deprecate using values of type null and bool as array offsets and when calling
array_key_exists()
Deprecating this would make the language more inconsistent by allowing this on array offsets but not on the function.I am slightly confused by what you mean by "allowing this on array offsets but not on the function".
However, null is not accepted by functions that accept scalar types, and bool would neither if my other RFC is approved.
Moreover, a type declaration of int|string accepted Stringable objects, however array offsets do not accept objects at all.I'll clarify:
You're allowed to do $array[null], $array[3.14], etc... and the key will coerce.
I expectarray_key_exists()to behave the same way as keys on array accesses do.
I'm confused what you mean as well. The deprecation is for both array offsets and when calling array_key_exists().
So $array[null] should output a deprecation just like the function, and there isn't any inconsistency.
Regards,
Theodore Brown
You're allowed to do $array[null], $array[3.14], etc... and the key will coerce.
I expectarray_key_exists()to behave the same way as keys on array accesses do.I'm confused what you mean as well. The deprecation is for both array offsets and when calling
array_key_exists().
So $array[null] should output a deprecation just like the function, and there isn't any inconsistency.
Okay now I understand. I misread the description and missed the word "and".
However, I still need some clarifications:
From the RFC:
Notably an offset of null is type juggled to the empty string "" rather than 0, contrasting with how values of type bool, float, and resources are cast to int.
Why is this wrong? Why must it get cast to 0?
From the RFC:
Which is even more surprising that the other operators that accept both string and int are bitwise operators and they throw a type error when attempting to use null with a value of type string.
I tried understanding this sentence multiple times but I just don't understand what it's saying.
Even presuming that the first "that" should maybe be "than", I still don't understand it.
Kind regards
Niels
There are a few things I will vote no for:
- Deprecate semicolon after case in switch statement.
People seem to use this and it doesn't seem harmful to have. Just because you don't like it doesn't mean we should yeet it.
Can you point to a project in current use where this syntax is intentionally used? I searched quite extensively
(even well beyond the top 1000 Composer packages where there are zero usages) and only found a tiny number of
accidental usages (e.g. where all the cases in a switch statement had a normal colon except one which had a semicolon typo).
Almost all of these were quickly fixed by sending a pull request.
Maybe the unnecessary legacy syntax doesn't seem harmful, but I disagree. Non-standard alternate syntax can cause confusion
about a potential behavioral difference, and sometimes can even hold back future features (for example, deprecating the curly
brace array access syntax in PHP 7.4 made it possible to implement property hooks in PHP 8.4).
I updated the RFC to document the planned deprecation message, as well a command which automatically fixes any usages in a project.
Kind regards,
Theodore Brown
There are a few things I will vote no for:
- Deprecate semicolon after case in switch statement.
People seem to use this and it doesn't seem harmful to have. Just because you don't like it doesn't mean we should yeet it.Can you point to a project in current use where this syntax is intentionally used? I searched quite extensively
(even well beyond the top 1000 Composer packages where there are zero usages) and only found a tiny number of
accidental usages (e.g. where all the cases in a switch statement had a normal colon except one which had a semicolon typo).
Almost all of these were quickly fixed by sending a pull request.
See https://externals.io/message/126000, in particular Derick's reply.
Also I'm sure there's a lot of brownfield PHP code that we have no idea about how it looks like.
Maybe the unnecessary legacy syntax doesn't seem harmful, but I disagree. Non-standard alternate syntax can cause confusion
about a potential behavioral difference, and sometimes can even hold back future features (for example, deprecating the curly
brace array access syntax in PHP 7.4 made it possible to implement property hooks in PHP 8.4).
Sure, but whether it opens up anything useful in the future is highly speculative.
I updated the RFC to document the planned deprecation message, as well a command which automatically fixes any usages in a project.
:+1:
Kind regards
Niels
Apologies for the duplicate; I missed CCing Internals previously.
There are a few things I will vote no for:
- Deprecate semicolon after case in switch statement.
People seem to use this and it doesn't seem harmful to have. Just because you don't like it doesn't mean we should yeet it.Can you point to a project in current use where this syntax is intentionally used? I searched quite extensively
(even well beyond the top 1000 Composer packages where there are zero usages) and only found a tiny number of
accidental usages (e.g. where all the cases in a switch statement had a normal colon except one which had a semicolon typo).
Almost all of these were quickly fixed by sending a pull request.See https://externals.io/message/126000, in particular Derick's reply.
I believe Derick was commenting specifically on using separate <?php ?> tags interleaved around
each switch, case, break, and endswitch statement (which there are no plans to deprecate). Based
on the follow-up replies from him and Tim, deprecating semicolon-terminated case statements
would not affect his xdebug.org site templates.
Also I'm sure there's a lot of brownfield PHP code that we have no idea about how it looks like.
Perhaps, but even if so the migration is automatic with a single php-cs-fixer command.
Maybe the unnecessary legacy syntax doesn't seem harmful, but I disagree. Non-standard alternate syntax can cause confusion
about a potential behavioral difference, and sometimes can even hold back future features (for example, deprecating the curly
brace array access syntax in PHP 7.4 made it possible to implement property hooks in PHP 8.4).Sure, but whether it opens up anything useful in the future is highly speculative.
I updated the RFC to document the planned deprecation message, as well a command which automatically fixes any usages in a project.
:+1:
Kind regards,
Theodore
Almost all of these were quickly fixed by sending a pull request.
See https://externals.io/message/126000, in particular Derick's reply.
I believe Derick was commenting specifically on using separate <?php ?> tags interleaved around
each switch, case, break, and endswitch statement (which there are no plans to deprecate). Based
on the follow-up replies from him and Tim, deprecating semicolon-terminated case statements
would not affect his xdebug.org site templates.
The use case we're talking about would be something like (indented to
avoid issues with Newsreaders):
<?switch ($foo):?>
<?case 1?>
If that code wouldn't trigger a deprecation notice, fine. However, we
had apparently introduced an inconsistency then.
Note that I do not advocate writing such code, but I wouldn't be
surprised if such code exists in the wild, but even more suprised if
such code would be found in a Composer package.
Christoph M. Becker
I believe Derick was commenting specifically on using separate <?php ?> tags interleaved around
each switch, case, break, and endswitch statement (which there are no plans to deprecate). Based
on the follow-up replies from him and Tim, deprecating semicolon-terminated case statements
would not affect his xdebug.org site templates.The use case we're talking about would be something like (indented to
avoid issues with Newsreaders):<?switch ($foo):?>
<?case 1?>
<p>1</p>
<?break?>
<?case 2?>
<p>2</p>
<?break?>
<?endswitch?>If that code wouldn't trigger a deprecation notice, fine. However, we
had apparently introduced an inconsistency then.
Hi Christoph,
I implemented the deprecation in a branch in order to test this 1.
That code would emit deprecation notices, and should be fixed by adding a colon
after each case statement, just like is required after the opening switch ($foo).
Note that I do not advocate writing such code, but I wouldn't be
surprised if such code exists in the wild, but even more suprised if
such code would be found in a Composer package.
If such code does exist anywhere, I expect it to be extremely rare, given how
many PHP devs seem to be surprised that the alternative case syntax is even possible.
Certainly this deprecation should be far less impactful than the curly brace
array/string access syntax that was successfully deprecated in PHP 7.4.
Sincerely,
Theodore Brown
Hello internals,
It is this time of year again where we proposed a list of deprecations to
add in PHP 8.5:
On the topic of deprecating __construct() in interfaces:
I'm thinking about constructors usually like this:
They are functions that are invoked statically (using the new keyword) on
the class before the object is created, and they execute on instance level,
after the object is created.
They are called as static methods, and they are very similar to static
factory methods, and for better or worse, static methods are supported in
interfaces.
So, in this sense, I think the pattern of defining a constructor in an
interface is useful.
This way, a factory that receives a class name implementing a specific
interface that defines a constructor will be able to accurately instantiate
that class in a simple way.
One could also argue that the deprecation could be solved easily by
replacing the constructor in the interface with a static factory method.
I think we should talk more on this, and I see that Ilija also touched on
it in his reply while I was drafting mine, with even more details.
Generally, I think that's what would be good for each deprecation, to have
a clear way of solving it noted in the RFC.
--
Alex
I'm thinking about constructors usually like this:
They are functions that are invoked statically (using thenewkeyword)
on the class before the object is created, and they execute on instance
level, after the object is created.They are called as static methods, and they are very similar to static
factory methods, and for better or worse, static methods are supported
in interfaces.
They're really more instance methods (they need an instance to exist for
them to act on, hence $this). The "new" operator creates the instance
and then the __construct method is called on that new instance.
One consequence of this is that the __construct method can be called
after instantiation (because in the normal course of things it is):
class Foo
{
public function __construct(public int $v=0)
{
echo "Constructed {$this->v}!";
}
}
$t = Foo::__construct(5);
$u = new Foo(17);
$u->__construct(42);
Le 2 juil. 2025 à 21:56, Gina P. Banyard internals@gpb.moe a écrit :
It is this time of year again where we proposed a list of deprecations to add in PHP 8.5:
Hi,
To reduce noise, I’ll be short.
General remark: For each deprecation, please research first if it’ll break code without easy replacement. Then, please provide an explicit deprecation message that will point to an alternative.
Some cases:
-
__construct() in interface. Useful feature, see: https://phpstan.org/blog/solving-phpstan-error-unsafe-usage-of-new-static
-
FILTER_CALLBACK: Useful in filter_var_array, as pointed by Rowan: https://externals.io/message/127849#127855
-
filter_input(),filter_input_array(), andfilter_has_var(): What if I want to operate on the original values of the superglobals?
—Claude
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
I'd also suggest deprecating building ext/readline with the Readline
library and
ext/dba with the GDBM library.
These two libraries are released under the GPL-3 license, which is not
compatible with PHP. In practice this means that PHP linked with
GPL-3-licensed
software should not be distributed, making it impractical for any server
environment beyond a local testing project. This issue isn't immediately
obvious, but many packagers need to be aware of it and avoid building with
these
libraries.
ext/readline works fine with the Editline library as an alternative,
ext/dba works fine with other handlers.
This suggestion would otherwise delay resolving the issue, as it would
require
an RFC vote - something I hoped to avoid in pull requests. But I suppose
that's
how it has to be handled.
See also:
I'd also suggest deprecating building ext/readline with the Readline library and
ext/dba with the GDBM library.These two libraries are released under the GPL-3 license, which is not
compatible with PHP. In practice this means that PHP linked with GPL-3-licensed
software should not be distributed, making it impractical for any server
environment beyond a local testing project. This issue isn't immediately
obvious, but many packagers need to be aware of it and avoid building with these
libraries.ext/readline works fine with the Editline library as an alternative,
ext/dba works fine with other handlers.This suggestion would otherwise delay resolving the issue, as it would require
an RFC vote - something I hoped to avoid in pull requests. But I suppose that's
how it has to be handled.
To add to this, GDBM also doesn't seem to work with our ext/dba tests;
QDBM did, however.
I ran into this earlier when doing the PPC CI work:
https://github.com/php/php-src/pull/17258#issuecomment-2585405491
I'd also suggest deprecating building ext/readline with the Readline library and
ext/dba with the GDBM library.These two libraries are released under the GPL-3 license, which is not
compatible with PHP. In practice this means that PHP linked with GPL-3-licensed
software should not be distributed, making it impractical for any server
environment beyond a local testing project. This issue isn't immediately
obvious, but many packagers need to be aware of it and avoid building with these
libraries.ext/readline works fine with the Editline library as an alternative,
ext/dba works fine with other handlers.This suggestion would otherwise delay resolving the issue, as it would require
an RFC vote - something I hoped to avoid in pull requests. But I suppose that's
how it has to be handled.See also:
Feel free to add a section to the RFC! :)
If we are going to deprecate some DBA libraries I would also chuck in some of the old DBA versions that we can't test in CI as they don't seem to be provided anywhere.
Best regards,
Gina P. Banyard
Hi,
I'd like to add a bit to the harmful/useful debate.
While writing a ->setAccessible(true) is not harmful per se, it's a clear indication one is following an outdated example/tutorial. New code should never contain it, not even for consistency (which could be argued for __sleep() if your codebase already has a couple of those). I would label a deprecation message for setAccessible as useful.
A semicolon for the switch cases, on the other hand, seems more like an easter egg and I'd love for it to stay just so PHP could keep that side of it's personality. I have similar feelings for 5d9 slowly incrementing to 6. It's funny and unused and an excellent trivia piece. It would be sad to add a "but it no longer works since 8.5" to the stories.
BR,
Juris
-----Original Message-----
From: Gina P. Banyard internals@gpb.moe
Sent: Wednesday, July 2, 2025 10:56 PM
To: PHP internals internals@lists.php.net
Subject: [PHP-DEV] [RFC] Deprecations for PHP 8.5
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
We propose to deprecate the following non-standard cast names:
- |(integer)|
- |(boolean)|
- |(double)|
- |(binary)|
Hello,
Just wondering is this going to affect settype() function? There is
already some disparity in that settype() supports
integer/boolean/double but not binary type (and additionally
supports null type).
We propose to deprecate the following non-standard cast names:
- (integer)
- (boolean)
- (double)
- (binary)
Hello,
Just wondering is this going to affect
settype()function? There is already some disparity in thatsettype()supportsinteger/boolean/doublebut notbinarytype (and additionally supportsnulltype).
I wasn't aware of the discrepencies with settype() so I added the deprecation of non-canonical type names to settype() as its own deprecation entry in the ext/standard section.
Thanks for bringing this to my attention!
Best regards,
Gina P. Banyard
Le 9 juil. 2025 à 14:21, Gina P. Banyard internals@gpb.moe a écrit :
We propose to deprecate the following non-standard cast names:
(integer)
(boolean)
(double)
(binary)
Hello,Just wondering is this going to affect
settype()function? There is already some disparity in thatsettype()supportsinteger/boolean/doublebut notbinarytype (and additionally supportsnulltype).I wasn't aware of the discrepencies with
settype()so I added the deprecation of non-canonical type names tosettype()as its own deprecation entry in the ext/standard section.
Thanks for bringing this to my attention!Best regards,
Gina P. Banyard
Hi,
A possible reason for wanting to use the non-canonical names in settype(), is that those names are returned by gettype(). Fictional example (not intended to be reasonable, only illustrative):
function settype_from(&$a, &b) {
return settype($a, gettype($b));
}
Personally, I have used "integer", etc. instead of "int", etc., in settype() in the past, because those were the “canonical” (as I perceived) forms returned by gettype(). I have slowly fallen out of that habit in the years after I began to use scalar type declarations (introduced in PHP 7).
—Claude
Le 9 juil. 2025 à 14:21, Gina P. Banyard internals@gpb.moe a écrit :
On Wednesday, 9 July 2025 at 08:17, Daikaras webmaster@daikaras.lt
wrote:We propose to deprecate the following non-standard cast names:
- |(integer)|
- |(boolean)|
- |(double)|
- |(binary)|
Hello,
Just wondering is this going to affect
settype()function? There
is already some disparity in thatsettype()supports
integer/boolean/doublebut notbinarytype (and additionally
supportsnulltype).I wasn't aware of the discrepencies with
settype()so I added the
deprecation of non-canonical type names tosettype()as its own
deprecation entry in the ext/standard section.
Thanks for bringing this to my attention!Best regards,
Gina P. Banyard
Hi,
A possible reason for wanting to use the non-canonical names in
settype(), is that those names are returned bygettype(). Fictional
example (not intended to be reasonable, only illustrative):function settype_from(&$a, &b) { return settype($a, gettype($b)); }Personally, I have used "integer", etc. instead of "int", etc., in
settype()in the past, because those were the “canonical” (as I
perceived) forms returned bygettype(). I have slowly fallen out of
that habit in the years after I began to use scalar type declarations
(introduced in PHP 7).—Claude
Oof, I didn't think of that. So this is a no go, IMO.
Hi,
A possible reason for wanting to use the non-canonical names in
settype(), is that those names are returned bygettype(). Fictional example (not intended to be reasonable, only illustrative):function settype_from(&$a, &b) { return settype($a, gettype($b)); }Personally, I have used "integer", etc. instead of "int", etc., in
settype()in the past, because those were the “canonical” (as I perceived) forms returned bygettype(). I have slowly fallen out of that habit in the years after I began to use scalar type declarations (introduced in PHP 7).
We are well aware of this "issue" and get_debug_type() was introduced in PHP 8 as a replacement for gettype() that returns the canonical names.
The one difference is that objects return the class name rather than "object".
I can add a deprecation of gettype() to nudge people to use get_debug_type() instead, if you think that's reasonable.
Best regards,
Gina P. Banyard
Le 10 juil. 2025 à 13:18, Gina P. Banyard internals@gpb.moe a écrit :
Hi,
A possible reason for wanting to use the non-canonical names in
settype(), is that those names are returned bygettype(). Fictional example (not intended to be reasonable, only illustrative):function settype_from(&$a, &b) { return settype($a, gettype($b)); }Personally, I have used "integer", etc. instead of "int", etc., in
settype()in the past, because those were the “canonical” (as I perceived) forms returned bygettype(). I have slowly fallen out of that habit in the years after I began to use scalar type declarations (introduced in PHP 7).We are well aware of this "issue" and
get_debug_type()was introduced in PHP 8 as a replacement forgettype()that returns the canonical names.
The one difference is that objects return the class name rather than "object".
I can add a deprecation ofgettype()to nudge people to useget_debug_type()instead, if you think that's reasonable.Best regards,
Gina P. Banyard
Hi,
Sorry for having forgotten to answer to this point. To be clearer, I think it is fine for settype() to keep support for the legacy names ("integer", "boolean", etc.) returned by gettype(), even if we deprecate the syntax (integer) $x, etc. The syntax (integer) is trivial to correct with a simple search-and-replace; such a correction is not straightforward for settype($a, $type) as $type is not necessarily a literal string. Moreover, the $type argument in settype() is not confusable with hypothetical user-defined types named, e.g., integer, as user-defined types are forbidden in settype() anyway.
—Claude
Hi
Am 2025-07-02 21:56, schrieb Gina P. Banyard:
Gina asked me to announce the plan to start the vote for her. Except for
the "Deprecate using values null as an array offset and when calling
array_key_exists()" proposal (which originally was the "Deprecate using
values of type null and bool as array offsets and when calling
array_key_exists()" proposal), which no longer includes the deprecation
of "bool" values as array offsets and got an updated explanation only
some minor typographical changes were made to the RFC since July, 9th.
This means the vast majority of the proposals have been unchanged for
roughly the last two weeks.
Therefore Gina plans to open the vote(s) on Friday (give or take).
Best regards
Tim Düsterhus
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
It is this time of year again where we proposed a list of deprecations to add in PHP 8.5:
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.
Hi Juliette,
I just analyzed the top 1500 Composer packages for a couple more of the proposed syntax
deprecations, and found the following:
Deprecate non-standard cast names:
197 non-standard casts in 25 unique packages.
Deprecate backticks as an alias for shell_exec:
49 backtick operator executions in 10 unique packages.
I find it ironic that the more widely used of these proposals has the least opposition to
deprecate (100% in favor so far), while deprecating semicolon-terminated case statements
(which has zero usages in the top 1500 packages) currently has more opposition than either
of these.
== 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).
Perhaps the deprecation seems unnecessary at first, but there is a non-zero cost to
maintaining this legacy alternate syntax in the language:
- It requires projects and coding style guides to choose and document which syntax to use.
- Coding style fixers like PHP-CS-Fixer and PHPCS have to implement and maintain fixers
to enforce one of the syntaxes. - Who knows whether the alternate syntax may block future proposals, as was the case for
the curly brace array/string offset syntax, which being deprecated in PHP 7.4 made it
possible to implement property hooks in PHP 8.4.
Kind regards,
Theodore
I just analyzed the top 1500 Composer packages for a couple more of the proposed syntax
deprecations, and found the following:Deprecate non-standard cast names:
197 non-standard casts in 25 unique packages.
Deprecate backticks as an alias for shell_exec:
49 backtick operator executions in 10 unique packages.
I find it ironic that the more widely used of these proposals has the least opposition to
deprecate (100% in favor so far), while deprecating semicolon-terminated case statements
(which has zero usages in the top 1500 packages) currently has more opposition than either
of these.
I would not necessarily expect backtick operators to be used in top
Composer packages. That is likely a feature used by some private shell
scripts; maybe sometimes quick and dirty through-away/ use-once scripts.
Christoph
I just analyzed the top 1500 Composer packages for a couple more of the proposed syntax
deprecations, and found the following:Deprecate non-standard cast names:
197 non-standard casts in 25 unique packages.
Deprecate backticks as an alias for shell_exec:
49 backtick operator executions in 10 unique packages.
I find it ironic that the more widely used of these proposals has the least opposition to
deprecate (100% in favor so far), while deprecating semicolon-terminated case statements
(which has zero usages in the top 1500 packages) currently has more opposition than either
of these.I would not necessarily expect backtick operators to be used in top
Composer packages. That is likely a feature used by some private shell
scripts; maybe sometimes quick and dirty through-away/ use-once scripts.
Hi Christoph,
Here's the list of usages:
https://gist.github.com/theodorejb/965633b9787475dfe64cc53dc941bc49
Some appear to be in tests or internal scripts, but not all.
E.g. the laravel\pulse usages, and the ones for console utilities.
Theodore
It is this time of year again where we proposed a list of deprecations to add in PHP 8.5:
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.
I just analyzed the top 1500 Composer packages for a couple more of the proposed syntax
deprecations, and found the following:Deprecate non-standard cast names:
197 non-standard casts in 25 unique packages.
Deprecate backticks as an alias for shell_exec:
49 backtick operator executions in 10 unique packages.
I find it ironic that the more widely used of these proposals has the least opposition to
deprecate (100% in favor so far), while deprecating semicolon-terminated case statements
(which has zero usages in the top 1500 packages) currently has more opposition than either
of these.
Hi Theodore,
Thank you for making the effort to gather more impact analysis. I wish
this kind of information would be mandatory for all deprecations and I
appreciate your efforts to help gather the info, though considering the
timing, it probably won't have any impact on the vote anymore.
I'm not surprised at all by the 0 usage of the semicolon-terminated case
statements in the top 1500 packages as it is forbidden by PSR2 and a
significant number of the top 1500 packages use PSR2/12/PER.
In contrast, PSR2/12/PER does not have any rules about the use of
non-standard cast names or the use of the backtick operator.
I also imagine if impact analysis would be done on, let's say package
20.000 to 22.000, instead of the top 1500 (or on both), results may be
interestingly different.
== 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).
Perhaps the deprecation seems unnecessary at first, but there is a non-zero cost to
maintaining this legacy alternate syntax in the language:
- It requires projects and coding style guides to choose and document which syntax to use.
- Coding style fixers like PHP-CS-Fixer and PHPCS have to implement and maintain fixers
to enforce one of the syntaxes.- Who knows whether the alternate syntax may block future proposals, as was the case for
the curly brace array/string offset syntax, which being deprecated in PHP 7.4 made it
possible to implement property hooks in PHP 8.4.
I don't think this reasoning is valid. Code style tools which have
support for scanning code against PSR2 already handle this and have for
a long time. There is no significant maintenance costs to that anymore.
The costs is in the past.
More than anything, even when the syntax would be deprecated and
eventually removed, these tools will still need to keep up support for
flagging these things as these tools are often enough used on older code
bases, which haven't been updated for the deprecation yet.
The deprecation and eventual removal will more likely increase
maintenance costs for these tools, as contributors less versed in the
intricacies of PHP will try to remove support or flag the test code used
as a parse error, which then means a maintainer will have to explain
this used to be supported by PHP etc etc.
It also means more detection tooling needs to be created - like in
PHPCompatibility - to detect this for years to come.
So no, in my estimation, deprecating this syntax will create more work,
not less work for code style fixing libraries and adjacent projects.
Smile,
Juliette
I just analyzed the top 1500 Composer packages for a couple more of the proposed syntax
deprecations, and found the following:Deprecate non-standard cast names:
197 non-standard casts in 25 unique packages.
Deprecate backticks as an alias for shell_exec:
49 backtick operator executions in 10 unique packages.
I find it ironic that the more widely used of these proposals has the least opposition to
deprecate (100% in favor so far), while deprecating semicolon-terminated case statements
(which has zero usages in the top 1500 packages) currently has more opposition than either
of these.Hi Theodore,
Thank you for making the effort to gather more impact analysis. I wish this kind of
information would be mandatory for all deprecations and I appreciate your efforts to
help gather the info, though considering the timing, it probably won't have any impact
on the vote anymore.
Hi Juliette,
You are welcome. It takes time to download top packages and write analysis scripts,
which is probably why it hasn't been done for more of the deprecation proposals.
I agree that it's generally nice to have impact data, though.
I'm not surprised at all by the 0 usage of the semicolon-terminated case statements
in the top 1500 packages as it is forbidden by PSR2 and a significant number of the
top 1500 packages use PSR2/12/PER.
In contrast, PSR2/12/PER does not have any rules about the use of non-standard cast
names or the use of the backtick operator.
This is not the case. Since PSR-12 the longer type keywords have been forbidden.
See https://www.php-fig.org/psr/psr-12/#25-keywords-and-types, which states:
"Short form of type keywords MUST be used i.e. bool instead of boolean,
int instead of integer etc."
Perhaps the deprecation seems unnecessary at first, but there is a non-zero cost to
maintaining this legacy alternate syntax in the language:
- It requires projects and coding style guides to choose and document which syntax to use.
- Coding style fixers like PHP-CS-Fixer and PHPCS have to implement and maintain fixers
to enforce one of the syntaxes.- Who knows whether the alternate syntax may block future proposals, as was the case for
the curly brace array/string offset syntax, which being deprecated in PHP 7.4 made it
possible to implement property hooks in PHP 8.4.I don't think this reasoning is valid. Code style tools which have support for scanning
code against PSR2 already handle this and have for a long time. There is no significant
maintenance costs to that anymore. The costs is in the past.More than anything, even when the syntax would be deprecated and eventually removed,
these tools will still need to keep up support for flagging these things as these
tools are often enough used on older code bases, which haven't been updated for the
deprecation yet.The deprecation and eventual removal will more likely increase maintenance costs for
these tools, as contributors less versed in the intricacies of PHP will try to remove
support or flag the test code used as a parse error, which then means a maintainer
will have to explain this used to be supported by PHP etc etc.It also means more detection tooling needs to be created - like in PHPCompatibility -
to detect this for years to come.So no, in my estimation, deprecating this syntax will create more work, not less
work for code style fixing libraries and adjacent projects.
Even if there is some short term effort to automate deprecation detection and fixes,
these tools will eventually drop support for PHP 8.x, at which point it will no longer
be necessary to maintain the fixers. Without the deprecation, there is extra work
indefinitely to ensure the fixers continue to work with the syntax in new PHP versions.
And tooling maintenance is not the only cost. One of the reasons I was motivated to
include the deprecation proposal was seeing all the discussions over the years in
Drupal related to this. See https://www.drupal.org/project/coding_standards/issues/2999367
(starts in 2018) and the referenced issues.
Deprecating this unnecessary legacy syntax will eventually remove the need to
maintain extra tooling and coding style documentation, and ultimately
eliminate a source of confusion and inconsistency in the language.
Sincerely,
Theodore
Hello internals,
As Tim announced a few days ago, I've opened the votes for the deprecations:
https://wiki.php.net/rfc/deprecations_php_8_5
Please remember that the wiki is only capable to handle a single vote at a time,
so please submit each vote you intend on casting individually.
Best regards,
Gina P. Banyard
Hello internals,
As Tim announced a few days ago, I've opened the votes for the
deprecations:
https://wiki.php.net/rfc/deprecations_php_8_5Please remember that the wiki is only capable to handle a single vote at a
time,
so please submit each vote you intend on casting individually.
Thank you for compiling the list, managing the process, and building in
process improvements like ensuring every vote has a deprecation message
attached.
It's very much appreciated how structured, well researched, and explained
things are!
And while adding my takes now, after weeks of discussion already taking
place, feels improper, but I'm excited to see the results and am looking
forward to voting and wanted to thank you for helping to clean up the
lanuage and allowing us to move forward.
Kind Regards,
Volker
--
Volker Dusch
Head of Engineering
Tideways GmbH
Königswinterer Str. 116
53227 Bonn
https://tideways.io/imprint
Sitz der Gesellschaft: Bonn
Geschäftsführer: Benjamin Außenhofer (geb. Eberlei)
Registergericht: Amtsgericht Bonn, HRB 22127
Hello internals,
As Tim announced a few days ago, I've opened the votes for the deprecations:
https://wiki.php.net/rfc/deprecations_php_8_5
Heads up, I've adjusted the header name for the driver specific build
flags to change deprecate to remove, matching the body of the proposal.
I suspect it probably won't change people's opinions on the matter, but
I'd like to be clear. I have not changed the vote names since I don't
know if that will break the existing polls. The body remains the same.
Thanks to Daniel for pointing this out.
I have not changed the vote names since I don't
know if that will break the existing polls.
I can confirm that that would have broken it.
cheers
Derick