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)]++;
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.
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
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 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
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
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