I'm unsure if DebugClassLoader should really do that. If the interface gets deprecated (it hasn't been yet, afaik), php will trigger its own deprecation notice. Also, this change will potentially product quite a few deprecation notices for third-party code that an application developer can't do much about.

The DebugClassLoader already produces a lot of deprecations for third-party code. That's ok because that's not controllable and that can push people to contribute to fix issues.

Also the \Serializable interface is definitely going to be removed (according to the content of the RFC).

So I think the question here is more something like : do we want the DebugClassLoader to report deprecations before they really happen to help users to be "future proof" ? Or in this case, do we want the DebugClassLoader to try to force a good practice to avoid potential problems ?

The DebugClassLoader already produces a lot of deprecations for third-party code

The fact it is third-party or userland code makes no difference as it triggers based on specific markers such as @deprecated only, meaning it's a feature you can opt-in via some phpdoc annotations.
This makes it discourage the use of a native PHP interface based on our own opinion/experience/usage, it could do the same for e.g. eval() in userland: that's not Symfony's scope to me, it's PHP one.

The RFC …

is written with a subsequent deprecation and removal of the severely broken Serializable interface in mind.

https://wiki.php.net/rfc/custom_object_serialization

In other words, there is the intention of deprecating the interface some time in the future. There is (to my knowledge) no RFC yet to actually deprecate it. So even if we would see it as the responsibility of DebugClassLoader to issue deprecation notices for this interface, implementing it now would be too early imho.

So let's add a check to enforce this in the Symfony namespace for now then.

@nicolas-grekas I restricted it to the Symfony namespace + I applied your idea to handle interfaces (but will need #31011 for tests to pass).

@fancyweb I rebased + added a 2nd commit on this PR. I did not update tests so that you can inspect the effect of the changes. Please have a look and squash+fix tests if you're OK. Let's discuss it if not.

@nicolas-grekas I have just checked your implementation. Three initial tests are failing. The failing tests are on "interfaces" cases.

With the initial implementation, deprecations are reported on interfaces that extends \Serializable, not on the classes that actually implement them. Example :

interface ExtendsSerializable extends \Serializable
{
}

class ImplementsAnInterfaceThatExtendsSerializable implements ExtendsSerializable
{
    public function serialize() {}
    public function unserialize($data) {}
}

With the initial implementation, deprecations are reported on the ExtendsSerializable interface : it should have the __serialize and __unserialize methods (to force their implementations).
With this implementation, deprecations are reported on the ImplementsAnInterfaceThatExtendsSerializable class.

Also, this implementation does fix the \ArrayIterator question but partially. If the final class overrides one of the serialize or unserialize methods, the deprecations are reported. IMHO, that shows an issue of this implementation. Example :

interface ExtendsSerializable extends \Serializable
{
}

class ImplementsAnInterfaceThatExtendsSerializable implements ExtendsSerializable
{
    public function __serialize(): array {}
    public function serialize() {}
    public function __unserialize(array $data): void {}
    public function unserialize($data) {}
}

class AnotherClass extends ImplementsAnInterfaceThatExtendsSerializable
{
    public function serialize() {}
}

Technically, AnotherClass is fine : it does implement the new mechanism (through inheritance). However, with the new implementation, the deprecations are reported for this class. With the initial implementation, deprecations are reported only on the ExtendsSerializable interface. I didn't take the time to see if it's easily fixable.

WDYT of those two points?

@nicolas-grekas I'm doing a tour of my open PR.

Is this one going somewhere or should we just close? The amount of time we both spent on this might not be worth it in the end 😄

Agreed :)
Thanks for giving it a try!