Hello internals,
Following the discussion that started at
https://externals.io/message/128226#128456 I wrote this RFC to formalize
our consensus on the topic.
TL;DR, this is about converting the deprecation of __sleep and __wakeup to
a documentation-based soft deprecation:
https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup
Cheers,
Nicolas
Hi
Am 2025-09-05 17:53, schrieb Nicolas Grekas:
Hello internals,
Following the discussion that started at
https://externals.io/message/128226#128456 I wrote this RFC to
formalize
our consensus on the topic.TL;DR, this is about converting the deprecation of __sleep and __wakeup
to
a documentation-based soft deprecation:
https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup
Thank you for the RFC. I have some comments:
I disagree with the phrasing that the RFC passed with a “narrow margin”.
While it is technically true, that this is the narrowest margin for
accepting an RFC, the necessary margins are already biased in favor of
not accepting an RFC. That the RFC was accepted means that a significant
majority of voters were in favor of the deprecation. I did not vote,
since I did not have sufficient time to form an opinion on the RFC, but
given the knowledge I've gained as part of the discussion I would now
vote in favor of the RFC.
The examples are biased. As an example, the initial “User” example has a
serialization hook that is completely useless. The other examples try to
replicate __sleep()'s broken behavior exactly, which seems to be a
relevant requirement in the real world for only a minority of users.
Similarly, I believe that the RFC overstates the cost of the
deprecation. From my experience a majority of serialization hooks will
just unconditionally throw an exception to prevent serialization. The
truth is probably somewhere in the middle.
The RFC correctly acknowleges that __sleep() is broken with regard to
private properties, but at the same time claims that the deprecation
does not fix a “correctness problem”, which is a contradiction.
The serialization mechanism is also a security sensitive part of the
language, the fewer moving parts there are, the better. Security is part
of the motivation for me.
That all said, as I've said before: I see that replacing __wakeup() by
__unserialize() is non-trivial and I would be okay with deferring that
one until we have some helper (e.g. **s**et_mangled_object_vars). But
__sleep() can just go away.
Best regards
Tim Düsterhus
Hi,
Hi
Am 2025-09-05 17:53, schrieb Nicolas Grekas:
Hello internals,
Following the discussion that started at
https://externals.io/message/128226#128456 I wrote this RFC to
formalize
our consensus on the topic.TL;DR, this is about converting the deprecation of __sleep and __wakeup
to
a documentation-based soft deprecation:
https://wiki.php.net/rfc/soft-deprecate-sleep-wakeupThank you for the RFC. I have some comments:
I disagree with the phrasing that the RFC passed with a “narrow margin”.
While it is technically true, that this is the narrowest margin for
accepting an RFC, the necessary margins are already biased in favor of
not accepting an RFC. That the RFC was accepted means that a significant
majority of voters were in favor of the deprecation. I did not vote,
since I did not have sufficient time to form an opinion on the RFC, but
given the knowledge I've gained as part of the discussion I would now
vote in favor of the RFC.
I think the point here was that it was close and the RFC itself was
misleading and omitted some important points that would like change the
final result.
The serialization mechanism is also a security sensitive part of the
language, the fewer moving parts there are, the better. Security is part
of the motivation for me.
Could you be more specific here? We do not consider issues (crashes and
similar) resulting from unserializing of the serialized string as security
issues because it must not come from the untrusted source (see
https://www.php.net/manual/en/function.unserialize.php ). I don't remember
any security issue in serialize / unserialize since this rule was set.
Kind Regards
Jakub
Hi
I think the point here was that it was close and the RFC itself was
Again, a 2/3 majority is not close. Twice the number of folks were in
favor than against the RFC.
misleading and omitted some important points that would like change the
final result.
I concede that “straight up improvement” might not be perfectly accurate
for __wakeup(), but for __sleep() it is accurate. __sleep() is
broken and there's a straight-forward migration to __serialize().
I appreciate that both of you communicated your concerns with the
proposed deprecation during the discussion, but you basically just said
“I believe the impact is too large”, which is not actionable feedback
for the RFC author and also doesn't help voters make an educated
decision. The point of the discussion phase is figuring out these
details together.
The serialization mechanism is also a security sensitive part of the
language, the fewer moving parts there are, the better. Security is part
of the motivation for me.Could you be more specific here? We do not consider issues (crashes and
similar) resulting from unserializing of the serialized string as security
issues because it must not come from the untrusted source (see
https://www.php.net/manual/en/function.unserialize.php ). I don't remember
any security issue in serialize / unserialize since this rule was set.
Even when only dealing with trusted data, unserialize needs to parse
inputs (which is already sufficiently dangerous in C) and it also needs
to deal with partial(ly initialized) object graphs all while executing
arbitrary (userland) code that may or may not interact in weird ways
(e.g. when error handlers get involved due to a bug in a custom
unserialize hook). And of course there can also be bugs with the
serializer that result in “trusted” output that triggers unexpected and
untested code-paths, particularly when references or cycles get
involved. When running with mixed PHP versions during an incremental
upgrade it might also be possible for serialization data to be emitted
by newer PHP versions that may not be anticipated by older PHP versions
and that trigger unexpected code-paths.
And then there's also stuff like
https://wiki.php.net/rfc/unserialize_warn_on_trailing_data, which can
happen due to bugs in a userland implementation even when not doing
unserialize($_GET['stuff']).
Saying that “unserialize is not security-relevant because you must only
feed it safe inputs” as an excuse to avoid making unserialize safer is
not helping anyone and is downplaying the risks involved in unserialization.
For all those reasons, I've intentionally tried to make the
unserialization hooks as robust as possible during review of newly added
classes (e.g. ext/random, ext/uri, and also
https://github.com/php/php-src/pull/19447), making them carefully check
the structure of the serialization input and also having tests that
verify robustness even when facing untrusted inputs, because that's just
something that will happen in the real world, despite the documentation
advising against it.
Best regards
Tim Düsterhus
Hi,
Hi
I think the point here was that it was close and the RFC itself was
Again, a 2/3 majority is not close. Twice the number of folks were in
favor than against the RFC.
I meant close to the actual threshold (not close vote). Again if single
person changed their mind because of the facts below (which is quite
likely), it might not have passed.
This RFC is just about to see if people can see that there is significantly
more effort needed for this migration. It just tries to make sure that
people can vote on the right description. If they don't think, that's wort
it to change the result, then so be it. But I think it's fair to provide an
RFC with a correct description so it can be properly decided.
misleading and omitted some important points that would like change the
final result.I concede that “straight up improvement” might not be perfectly accurate
for__wakeup(), but for__sleep()it is accurate.__sleep()is
broken and there's a straight-forward migration to__serialize().I appreciate that both of you communicated your concerns with the
proposed deprecation during the discussion, but you basically just said
“I believe the impact is too large”, which is not actionable feedback
for the RFC author and also doesn't help voters make an educated
decision. The point of the discussion phase is figuring out these
details together.
Yeah as I mentioned it was also my fault not to point this out sooner but
it's hard to verify every single thing in detail if there are like 50
deprecations proposed.
The serialization mechanism is also a security sensitive part of the
language, the fewer moving parts there are, the better. Security is part
of the motivation for me.Could you be more specific here? We do not consider issues (crashes and
similar) resulting from unserializing of the serialized string as
security
issues because it must not come from the untrusted source (see
https://www.php.net/manual/en/function.unserialize.php ). I don't
remember
any security issue in serialize / unserialize since this rule was set.Even when only dealing with trusted data, unserialize needs to parse
inputs (which is already sufficiently dangerous in C) and it also needs
to deal with partial(ly initialized) object graphs all while executing
arbitrary (userland) code that may or may not interact in weird ways
(e.g. when error handlers get involved due to a bug in a custom
unserialize hook). And of course there can also be bugs with the
serializer that result in “trusted” output that triggers unexpected and
untested code-paths, particularly when references or cycles get
involved. When running with mixed PHP versions during an incremental
upgrade it might also be possible for serialization data to be emitted
by newer PHP versions that may not be anticipated by older PHP versions
and that trigger unexpected code-paths.
I understand your concern about the complexity but this can apply to many
other parts in php-src. As I'm sure you know, this still wouldn't likely to
be considered as a security issue.
And then there's also stuff like
https://wiki.php.net/rfc/unserialize_warn_on_trailing_data, which can
happen due to bugs in a userland implementation even when not doing
unserialize($_GET['stuff']).
This could be closer but we wouldn't like find exploit either. At least
this wasn't even raised as a security issue so I guess you were expecting
that not to be a security problem.
Saying that “unserialize is not security-relevant because you must only
feed it safe inputs” as an excuse to avoid making unserialize safer is
not helping anyone and is downplaying the risks involved in
unserialization.
I don't have problem with making unserialize safer as there might be users
that use it improperly. But we shouldn't be saying that this is a security
sensitive part when we don't consider those sort of issues as security
issues because none of those issues will get fixed in our security support
only releases. In that sense I don't think we can consider it as a security
sensitive part.
Kind regards
Jakub
Hi
Am 2025-09-08 23:14, schrieb Jakub Zelenka:
I understand your concern about the complexity but this can apply to
many
other parts in php-src. As I'm sure you know, this still wouldn't
likely to
be considered as a security issue.
I've intentionally said “security sensitive”. I believe the risk of
security issues for the unserializer is significantly higher than in
other parts of the language and I also believe that by keeping
complexity down it is both easier to verify correctness and also to fix
any bugs that crop up. From what I see __wakeup() and __unserialize()
work quite differently internally. When there's __unserialize(), the
deserialization process only creates an empty object shell (similarly to
newInstanceWithoutConstructor) and then calls __unserialize() at the
very end. For __wakeup() all the properties are filled directly and then
__wakeup() is called at the end. In both cases the destructor is skipped
for all following objects once one of the deserialization hooks fails.
For __wakeup() this has the interesting effect that in case of circular
structures, some objects may appear to already be properly initialized
(all the properties are there), but __wakeup() has not executed yet,
potentially making them unsafe to touch. In case of __unserialize() the
objects are clearly in a partially initialized state (e.g. properties
being uninit), which I'd claim is safer:
<?php
class A {
public $a;
public function __construct(public string $name)
{
}
public function __unserialize(array $data): void
{
$this->a = $data['a'];
$this->name = $data['name'];
echo "Waking up ", $this->name, PHP_EOL;
var_dump($this->a->name);
}
public function __wakeup(): void
{
echo "Waking up ", $this->name, PHP_EOL;
var_dump($this->a->name);
}
public function __destruct()
{
echo __METHOD__, PHP_EOL;
}
}
$a = new A('A');
$a->a = new A('B');
$a->a->a = new A('C');
$a->a->a->a = $a;
echo "Before", PHP_EOL;
var_dump(unserialize(serialize($a)));
echo "After", PHP_EOL;
In case of __unserialize() the unsafe access to $this->a->name will
throw, whereas in __wakeup() it will return A, despite A not being
fully available yet. Similarly skipping the destructor for an empty
object shell is safer than skipping the destructor for an object that
may appear usable.
Saying that “unserialize is not security-relevant because you must
only
feed it safe inputs” as an excuse to avoid making unserialize safer is
not helping anyone and is downplaying the risks involved in
unserialization.I don't have problem with making unserialize safer as there might be
users
that use it improperly. But we shouldn't be saying that this is a
security
sensitive part when we don't consider those sort of issues as security
issues because none of those issues will get fixed in our security
support
only releases. In that sense I don't think we can consider it as a
security
sensitive part.
The unserializer already contains quite a bit of logic to make it as
safe as possible, e.g. running the unserialization hooks only at the
very end and skipping destructors for objects where the unserialization
hook didn't successfully run. The forefathers definitely considered
possible edge cases that might lead to security issues.
Best regards
Tim Düsterhus
Hi,
Hi
Am 2025-09-08 23:14, schrieb Jakub Zelenka:
I understand your concern about the complexity but this can apply to
many
other parts in php-src. As I'm sure you know, this still wouldn't
likely to
be considered as a security issue.I've intentionally said “security sensitive”. I believe the risk of
security issues for the unserializer is significantly higher than in
other parts of the language and I also believe that by keeping
complexity down it is both easier to verify correctness and also to fix
any bugs that crop up. From what I see __wakeup() and __unserialize()
work quite differently internally. When there's __unserialize(), the
deserialization process only creates an empty object shell (similarly to
newInstanceWithoutConstructor) and then calls __unserialize() at the
very end. For __wakeup() all the properties are filled directly and then
__wakeup() is called at the end. In both cases the destructor is skipped
for all following objects once one of the deserialization hooks fails.For __wakeup() this has the interesting effect that in case of circular
structures, some objects may appear to already be properly initialized
(all the properties are there), but __wakeup() has not executed yet,
potentially making them unsafe to touch. In case of __unserialize() the
objects are clearly in a partially initialized state (e.g. properties
being uninit), which I'd claim is safer:<?php class A { public $a; public function __construct(public string $name) { } public function __unserialize(array $data): void { $this->a = $data['a']; $this->name = $data['name']; echo "Waking up ", $this->name, PHP_EOL; var_dump($this->a->name); } public function __wakeup(): void { echo "Waking up ", $this->name, PHP_EOL; var_dump($this->a->name); } public function __destruct() { echo __METHOD__, PHP_EOL; } } $a = new A('A'); $a->a = new A('B'); $a->a->a = new A('C'); $a->a->a->a = $a; echo "Before", PHP_EOL; var_dump(unserialize(serialize($a))); echo "After", PHP_EOL;In case of
__unserialize()the unsafe access to$this->a->namewill
throw, whereas in__wakeup()it will returnA, despiteAnot being
fully available yet. Similarly skipping the destructor for an empty
object shell is safer than skipping the destructor for an object that
may appear usable.Saying that “unserialize is not security-relevant because you must
only
feed it safe inputs” as an excuse to avoid making unserialize safer is
not helping anyone and is downplaying the risks involved in
unserialization.I don't have problem with making unserialize safer as there might be
users
that use it improperly. But we shouldn't be saying that this is a
security
sensitive part when we don't consider those sort of issues as security
issues because none of those issues will get fixed in our security
support
only releases. In that sense I don't think we can consider it as a
security
sensitive part.The unserializer already contains quite a bit of logic to make it as
safe as possible, e.g. running the unserialization hooks only at the
very end and skipping destructors for objects where the unserialization
hook didn't successfully run. The forefathers definitely considered
possible edge cases that might lead to security issues.
I can see what you mean but you could say in the same way that many parts
in the engine and other parts are security sensitive. Almost anything that
is complex can lead to a security issue given some preconditions. The fact
is that we have not had any serialization issue for a long time so to me
there are places that are more security sensitive and more problematic than
seriallization.
Kind regards,
Jakub
Hi,
I disagree with the phrasing that the RFC passed with a “narrow margin”.
I just updated the wording so it now says:
A recent RFC to deprecate the __sleep() and __wakeup() magic methods in
favor of __serialize() and __unserialize() passed (18–9), but only just met
the required 2/3 majority.
Hope it's better! :)
Kind regards,
Jakub
Hi
Am 2025-09-10 17:39, schrieb Jakub Zelenka:
A recent RFC to deprecate the __sleep() and __wakeup() magic methods
in
favor of __serialize() and __unserialize() passed (18–9), but only just
met
the required 2/3 majority.Hope it's better! :)
Thank you, the updated phrasing is better indeed. Factually stating that
it just met the required majority (while stating the majority) is
something different than saying it a close vote, which leaves room for
ambiguity.
Best regards
Tim Düsterhus
Hi Tim
Hello internals,
Following the discussion that started at
https://externals.io/message/128226#128456 I wrote this RFC to
formalize
our consensus on the topic.TL;DR, this is about converting the deprecation of __sleep and __wakeup
to
a documentation-based soft deprecation:
https://wiki.php.net/rfc/soft-deprecate-sleep-wakeupThank you for the RFC. I have some comments:
I disagree with the phrasing that the RFC passed with a “narrow margin”.
While it is technically true, that this is the narrowest margin for
accepting an RFC, the necessary margins are already biased in favor of
not accepting an RFC. That the RFC was accepted means that a significant
majority of voters were in favor of the deprecation. I did not vote,
since I did not have sufficient time to form an opinion on the RFC, but
given the knowledge I've gained as part of the discussion I would now
vote in favor of the RFC.
Jakub addressed that in a sub-thread.
The examples are biased. As an example, the initial “User” example has a
serialization hook that is completely useless. The other examples try to
replicate__sleep()'s broken behavior exactly, which seems to be a
relevant requirement in the real world for only a minority of users.
The quantitative argument is not the only measure of the impact.
The RFC explains why - qualitatively - the RFC will have a significant
impact.
For the quantitative part, we can talk forever before agreeing.
Similarly, I believe that the RFC overstates the cost of the
deprecation. From my experience a majority of serialization hooks will
just unconditionally throw an exception to prevent serialization. The
truth is probably somewhere in the middle.
I'm not sure why you talk about throwing hooks. Those are not concerned so
that's orthogonal to the points made.
From the small but not negligible share of the community I'm working with,
having both Doctrine and Symfony impacted means the impact will be
significant.
Add that to the fact the "fix" is risky (what the RFC explains), and this
will be a costly RFC for sure.
Note that as Jakub figured out in the latest example he added, not only
library-level codebases will need complex fixes: e.g. app-side user objects
that use __sleep/wakeup and that are put into a session storage will need
something as complex to address the deprecation without disrupting their
connected users.
The RFC correctly acknowleges that
__sleep()is broken with regard to
private properties, but at the same time claims that the deprecation
does not fix a “correctness problem”, which is a contradiction.
I clarified this aspect in the RFC this way ("No technical urgency"
section):
Some consider that __sleep() is broken because it is incompatible with
nested private properties. Yet, this is more of a limitation rather than
something being broken: many use cases don't need access to private
properties and are just fine with the method. When one needs to overcome
this limitation, one can migrate to __serialize, on an opt-in basis.
The serialization mechanism is also a security sensitive part of the
language, the fewer moving parts there are, the better. Security is part
of the motivation for me.
Jakub addressed that in a sub-thread also.
That all said, as I've said before: I see that replacing __wakeup() by
__unserialize() is non-trivial and I would be okay with deferring that
one until we have some helper (e.g.**s**et_mangled_object_vars). But
__sleep() can just go away.
We've added a note in the "Future scope" section, phrased like this:
Consider dealing with __wakeup / __sleep separately as the impact might
be specific to each one
Cheers,
Nicolas
Hi
Am 2025-09-10 18:17, schrieb Nicolas Grekas:
The examples are biased. As an example, the initial “User” example has
a
serialization hook that is completely useless. The other examples try
to
replicate__sleep()'s broken behavior exactly, which seems to be a
relevant requirement in the real world for only a minority of users.The quantitative argument is not the only measure of the impact.
The RFC explains why - qualitatively - the RFC will have a significant
impact.
For the quantitative part, we can talk forever before agreeing.
The product of both is the relevant metric. This appears to be a
high-impact deprecation for a small amount of existing users. I believe
that is less bad than a small-impact deprecation for a large amount of
users. That's also why I voted against the driver-specific PDO
constants, since the alternative is only available since the last
version, giving folks little time for a natural migration. In this case,
the alternative is available for quite some time already.
The impact to existing users is also not the only impact deprecating or
not deprecating something will have. As an example, the RFC ignores the
positive impact for folks that are newly writing some code by pointing
them towards the “correct” solution. Something that is just in the
documentation might as well not exist. Some of the documentation pages
for functions I proposed to deprecate in past PHP versions are full of
warnings (sometimes 3 of them), but folks still reach towards using
those functions.
Similarly, I believe that the RFC overstates the cost of the
deprecation. From my experience a majority of serialization hooks will
just unconditionally throw an exception to prevent serialization. The
truth is probably somewhere in the middle.I'm not sure why you talk about throwing hooks. Those are not concerned
so
that's orthogonal to the points made.
If the majority of serialization hooks will just throw, this means that
the original RFC did not affect them, which then raises the question of
whether or not claims such as “many users” are accurate.
The RFC correctly acknowleges that
__sleep()is broken with regard
to
private properties, but at the same time claims that the deprecation
does not fix a “correctness problem”, which is a contradiction.I clarified this aspect in the RFC this way ("No technical urgency"
section):Some consider that __sleep() is broken because it is incompatible
with
nested private properties. Yet, this is more of a limitation rather
than
something being broken: many use cases don't need access to private
properties and are just fine with the method. When one needs to
overcome
this limitation, one can migrate to __serialize, on an opt-in basis.
That is better, thank you. However “many use cases do not require
private properties” is again making a claim that I'm not sure is
supported by data. I don't have any better data, but:
- Using private properties is a best practice for encapsulation.
- When I serialize objects, I want to get the original data back out.
This suggests to me that supporting private properties properly cannot
be an afterthought. Note that the issue with __sleep() is with private
properties of parent and child classes. If inheritance doesn't get
involved, __sleep() works just fine, but that case is also the case
where migration to __serialize() is easy to do, since you the entire
section (3) of the RFC doesn't apply.
In other words, the large migration complexity exists exactly in the
cases that are not handled well by __sleep(), which I do not believe is
coincidental! As a user you have a choice between continuing using
__sleep() and breaking private properties or migrating to __serialize(),
which will be painful once and then work will after that. To me the
choice is clear: Doing the migration, since then I will not need to deal
with the issues arising of broken inheritance for eternity.
That all said, as I've said before: I see that replacing __wakeup() by
__unserialize() is non-trivial and I would be okay with deferring that
one until we have some helper (e.g.**s**et_mangled_object_vars).
But
__sleep() can just go away.We've added a note in the "Future scope" section, phrased like this:
Consider dealing with __wakeup / __sleep separately as the impact
might
be specific to each one
Thank you.
Best regards
Tim Düsterhus
On Mon, Sep 8, 2025 at 8:21 PM Nicolas Grekas nicolas.grekas+php@gmail.com
wrote:
Hello internals,
Following the discussion that started at
https://externals.io/message/128226#128456 I wrote this RFC to formalize
our consensus on the topic.TL;DR, this is about converting the deprecation of __sleep and __wakeup to
a documentation-based soft deprecation:
https://wiki.php.net/rfc/soft-deprecate-sleep-wakeupCheers,
Nicolas
The PHP 8.5 RM team has discussed this internally, and arrived at the
following. A full explanation of our reasoning follows.
- Given the accepted RFC for deprecating
__sleep()and__wakeup()in
PHP 8.5, we should aim to merge the deprecation in time for PHP 8.5, i.e.
before PHP-8.5 is branched on September 23. - If the RFC to switch the deprecation to a "soft deprecation" is accepted,
the RM team is comfortable with landing a revert of the deprecation as long
as the revert can land before RC2.
Our reasoning is as follows ("hard deprecation" means the warnings, "soft
deprecation" is just the documentation):
-
We cannot assume that the soft deprecation RFC will be accepted.
However, if we wait until we know for certain that the RFC fails, it would
be too late to then merge the hard deprecation. By our math, if the soft
deprecation RFC had exactly 2 weeks of discussion and then 2 weeks of
voting, the earliest it would close is October 4, with RC2 being tagged
October 7. -
Since we cannot merge the hard deprecation after RC1, the hard
deprecation either needs to go into PHP 8.5 before RC1, or be delayed until
the next release. Since there was an RFC for doing the deprecation in PHP
8.5 that got accepted, 8.5 should be preferred. -
Having a hard deprecation in PHP 8.5, and converting it to a soft
deprecation in PHP 8.6 (or PHP 9.0, whatever is next), does not make sense.
For the soft deprecation RFC to be meaningful, we would need to not have
the hard deprecation warnings in PHP 8.5. -
If the hard deprecation is implemented for 8.5 (per note 2) but the soft
deprecation RFC is accepted, then (per note 3) we should remove the hard
deprecation warnings from PHP 8.5. However, such a relatively large change
should not be made too close to the GA release of PHP 8.5.0. Release
candidates are meant to match the eventual release as closely as possible. -
Given the minimum schedule outlined in note 1 above, there are a few
days before the soft deprecation RFC could finish voting and when RC2 is
packaged. This should be enough time to land a revert of the hard
deprecation, given that a) the patch can be reviewed and approved before
the RFC finishes, and b) the patch is likely to be just a revert of the
original deprecation patches. By removing the warnings from RC2, community
developers waiting to test the release candidates until after the warnings
were removed can have 3 release candidates to do so.
Thanks,
--Daniel Scherzer, Volker Dusch, and Pierrick Charron
Hi Daniel,
Thanks for the update.
Le lun. 8 sept. 2025 à 19:25, Daniel Scherzer daniel.e.scherzer@gmail.com
a écrit :
On Mon, Sep 8, 2025 at 8:21 PM Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:Hello internals,
Following the discussion that started at
https://externals.io/message/128226#128456 I wrote this RFC to formalize
our consensus on the topic.TL;DR, this is about converting the deprecation of __sleep and __wakeup
to a documentation-based soft deprecation:
https://wiki.php.net/rfc/soft-deprecate-sleep-wakeupCheers,
NicolasThe PHP 8.5 RM team has discussed this internally, and arrived at the
following. A full explanation of our reasoning follows.
- Given the accepted RFC for deprecating
__sleep()and__wakeup()in
PHP 8.5, we should aim to merge the deprecation in time for PHP 8.5, i.e.
before PHP-8.5 is branched on September 23.- If the RFC to switch the deprecation to a "soft deprecation" is
accepted, the RM team is comfortable with landing a revert of the
deprecation as long as the revert can land before RC2.Our reasoning is as follows ("hard deprecation" means the warnings, "soft
deprecation" is just the documentation):
We cannot assume that the soft deprecation RFC will be accepted.
However, if we wait until we know for certain that the RFC fails, it would
be too late to then merge the hard deprecation. By our math, if the soft
deprecation RFC had exactly 2 weeks of discussion and then 2 weeks of
voting, the earliest it would close is October 4, with RC2 being tagged
October 7.Since we cannot merge the hard deprecation after RC1, the hard
deprecation either needs to go into PHP 8.5 before RC1, or be delayed until
the next release. Since there was an RFC for doing the deprecation in PHP
8.5 that got accepted, 8.5 should be preferred.Having a hard deprecation in PHP 8.5, and converting it to a soft
deprecation in PHP 8.6 (or PHP 9.0, whatever is next), does not make sense.
For the soft deprecation RFC to be meaningful, we would need to not have
the hard deprecation warnings in PHP 8.5.If the hard deprecation is implemented for 8.5 (per note 2) but the
soft deprecation RFC is accepted, then (per note 3) we should remove the
hard deprecation warnings from PHP 8.5. However, such a relatively large
change should not be made too close to the GA release of PHP 8.5.0. Release
candidates are meant to match the eventual release as closely as possible.Given the minimum schedule outlined in note 1 above, there are a few
days before the soft deprecation RFC could finish voting and when RC2 is
packaged. This should be enough time to land a revert of the hard
deprecation, given that a) the patch can be reviewed and approved before
the RFC finishes, and b) the patch is likely to be just a revert of the
original deprecation patches. By removing the warnings from RC2, community
developers waiting to test the release candidates until after the warnings
were removed can have 3 release candidates to do so.
The interesting thing with that approach is that all libs that do test
with php-src dev-master will see the deprecation, so at least some OSS
maintainers will work on addressing this as we speak.
This might give useful hints about the impact of the deprecation (like the
feedback from Sebastian on phpunit, followed by one from Thomas stating
this resulted in a perf issue).
On Symfony, we have 3 branches maintained: the next major is already free
from sleep/wakeup; the next minor has BC layers that look like the ones
presented in the RFC; and the next patch-level is not free from the
deprecation: we addressed throwing/internal/final cases and chose the
option to silence in the CI instead for the complex cases. The CI is still
not green: dependencies will have to be patched also. I've no idea how much
time this will take. But I know it's a significant effort - way more than
usual for a deprecation!
As a corollary to your message, I'm wondering what would be the earliest we
could open the vote?
Our policy on the topic says:
There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.
Other RFCs might use a smaller timeframe, but it should be at least a week.
Should it be one or two weeks?
The earlier the better for everyone I think (I don’t expect to convince Tim
either way, so from my side that part of the discussion is done. ;) )
Cheers,
Nicolas
Hi
As a corollary to your message, I'm wondering what would be the earliest we
could open the vote?
Our policy on the topic says:There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.
Other RFCs might use a smaller timeframe, but it should be at least a week.Should it be one or two weeks?
Clarifying this is part of my current policy RFC. The established
consensus (and expectations from users) is at least 2 weeks of
discussion for everything.
That would be Friday, September 19th 2025 17:54 Europe/Paris then.
Even when taking into account the expectation that changes to the RFC
text requires additional discussion (my policy RFC is also formalizing
that), I'd say that the changes you have made to the RFC are only
clarification that do not change the actual proposal, which would be a
minor change under the definition of my proposal.
Therefore I'd say that starting the vote at any point after the above
mentioned time is strictly within policy.
(I don’t expect to convince Tim
either way, so from my side that part of the discussion is done. ;) )
I agree.
I'm also okay with the updated RFC text. While there are still some
things that I believe could be presented differently (as I outlined in
my email earlier today), it reasonable fairly represents the situation.
I still disagree with the proposal itself, of course :-)
Best regards
Tim Düsterhus
Hi,
On Fri, Sep 5, 2025 at 5:55 PM Nicolas Grekas nicolas.grekas+php@gmail.com
wrote:
Hello internals,
Following the discussion that started at
https://externals.io/message/128226#128456 I wrote this RFC to formalize
our consensus on the topic.TL;DR, this is about converting the deprecation of __sleep and __wakeup to
a documentation-based soft deprecation:
https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup
We just had a discussion privately about this and I came with one example
that would be worth to add here. It is about storing the serialized string
where application needs to care about working correctly with the old
format. For example when object is serialized, that string is stored into
database. So when the application is deployed, it should still work in the
same way when unserializing the string.
If __sleep is used to serialize private properties (not all but just some),
then those property names are stored in the mangled format ("\x00" .
self::class . "\x00" prefix). It means to make it compatible in
__serialize, the application has to mangle property names - this can be
done either manually prefixing the name or using get_mangled_object_vars
and filter the mangled names. Alternatively it could use __serialize with
the new names but then it will need to deal with new and old (mangled)
formats in __unserialize. In any case it means that the users will be
required to deal with the mangled property name and get some understanding
of mangling.
Kind regards,
Jakub
Hi,
Hi,
On Fri, Sep 5, 2025 at 5:55 PM Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:Hello internals,
Following the discussion that started at
https://externals.io/message/128226#128456 I wrote this RFC to formalize
our consensus on the topic.TL;DR, this is about converting the deprecation of __sleep and __wakeup
to a documentation-based soft deprecation:
https://wiki.php.net/rfc/soft-deprecate-sleep-wakeupWe just had a discussion privately about this and I came with one example
that would be worth to add here. It is about storing the serialized string
where application needs to care about working correctly with the old
format. For example when object is serialized, that string is stored into
database. So when the application is deployed, it should still work in the
same way when unserializing the string.If __sleep is used to serialize private properties (not all but just
some), then those property names are stored in the mangled format ("\x00" .
self::class . "\x00" prefix). It means to make it compatible in
__serialize, the application has to mangle property names - this can be
done either manually prefixing the name or using get_mangled_object_vars
and filter the mangled names. Alternatively it could use __serialize with
the new names but then it will need to deal with new and old (mangled)
formats in __unserialize. In any case it means that the users will be
required to deal with the mangled property name and get some understanding
of mangling.
I just had a chat with Nicolas and he asked me to add it and co-author the
RFC so the section added here:
https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup#complex_handling_of_mangled_property_names_with_persistent_storage
Kind regards,
Jakub
Am 10.09.2025 um 15:23 schrieb Jakub Zelenka:
If __sleep is used to serialize private properties (not all but just
some), then those property names are stored in the mangled format
("\x00" . self::class . "\x00" prefix). It means to make it compatible in
__serialize, the application has to mangle property names - this can be
done either manually prefixing the name or using get_mangled_object_vars
and filter the mangled names. Alternatively it could use __serialize with
the new names but then it will need to deal with new and old (mangled)
formats in __unserialize. In any case it means that the users will be
required to deal with the mangled property name and get some understanding
of mangling.
On the off-chance this might be useful for somebody following this thread,
this is what the prefixing approach looks like:
https://github.com/sebastianbergmann/php-code-coverage/blob/12.3.7/src/CodeCoverage.php#L92-L110
Sebastian Bergmann sebastian@php.net hat am 11.09.2025 08:33 CEST geschrieben:
Am 10.09.2025 um 15:23 schrieb Jakub Zelenka:
If __sleep is used to serialize private properties (not all but just
some), then those property names are stored in the mangled format
("\x00" . self::class . "\x00" prefix). It means to make it compatible in
__serialize, the application has to mangle property names - this can be
done either manually prefixing the name or using get_mangled_object_vars
and filter the mangled names. Alternatively it could use __serialize with
the new names but then it will need to deal with new and old (mangled)
formats in __unserialize. In any case it means that the users will be
required to deal with the mangled property name and get some understanding
of mangling.On the off-chance this might be useful for somebody following this thread,
this is what the prefixing approach looks like:https://github.com/sebastianbergmann/php-code-coverage/blob/12.3.7/src/CodeCoverage.php#L92-L110
This serialize is currently not very optimal. E.g. Pest uses "--coverage-php" and in my setup SebastianBergmann\CodeCoverage\Report\PHP::process() then consumes gigabytes of ram, >500M on disk and >20s extra time to get the coverage report.
Regards
Thomas
Hello internals,
Following the discussion that started at
https://externals.io/message/128226#128456 I wrote this RFC to formalize
our consensus on the topic.TL;DR, this is about converting the deprecation of __sleep and __wakeup
to
a documentation-based soft deprecation:
https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup
That's very interesting! Didn't know it's possible to soft-deprecate in
PHP.
And by chance if you know it: Where is the database of all
soft-deprecations PHP has so far? Hypertext reference appreceated.
-- hakre
Hi all,
Hello internals,
Following the discussion that started at
https://externals.io/message/128226#128456 I wrote this RFC to formalize
our consensus on the topic.TL;DR, this is about converting the deprecation of __sleep and __wakeup to
a documentation-based soft deprecation:
https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup
The 2 weeks discussion period on this RFC is coming to an end without
significant activity anymore.
I therefore plan to start the vote on Saturday 20th.
Cheers,
Nicolas