root class named services are supported. What is not supported for them is the shortcut allowing to guess the class name from the id.

Correct. My reasoning is, if My\Class: ~ is described as a class named service then \MyClass: ~ is a root class named service :)

👎 on my side: there should be only one valid id. Normalization creates alternative ways and leads to issues. We deprecated lowercasing for this reason.

I propose to deprecate leading slashes in service ids

So yes, a leading \ would throw eventually. No normalization.

For the class: attribute normalization could work, but on 2nd thought i prefer a deprecation here as well. Exactly for the reasons you mentioned.

But if there are no technical reasons, deprecating for the sake of it is not worth it IMHO.

Fair, that's why I opened the RFC.

You're right, it's purely a DX issue. No technical reason.

In a way this error is just a weird side effect:

The definition for "\My\DateTime" has no class attribute,
and appears to reference a class or interface in the global namespace.
Leaving out the "class" attribute is only allowed for namespaced classes.

Nevertheless, we can settle by qualifying it a doc issue. Then i'll go back to symfony/symfony-docs#8403 :)

Sure, it's always worth asking, and that's just my 2cts :)

@ro0NL thanks for starting this discussion. I disagree about "polluting" the Symfony Docs with these minor details. This can be solved with a great error message generated by Symfony when this happens.

The current error message is good, but I'd like to propose a minor reword to make it more clear what the developer must do to solve it:

The "\My\DateTime" service definition must include the "class" attribute because
it references a class or interface in the global PHP namespace. Leaving out the
"class" attribute is only allowed for namespaced classes.