IMHO, there are two no-gos:

• using a convention to "sniff" what "looks enough like" a class or not;
• using class_exists, because that would slow down the creation of the compiler, and more importantly make it context-sensitive.

Which means I'm leaning towards answering "no, we can't" to your "Should we care?" question.

That being said, what about catching the Error that comes up when a class is missing, and turn it into some friendlier error message when we find that the missing class has exactly the same name than the service id that we were asking for?

what about catching the Error that comes up when a class is missing, and turn it into some friendlier error message when we find that the missing class has exactly the same name than the service id that we were asking for?

It'll indeed be a step forward, but how would you proceed in order to achieve that? 😕

The two possibilities I see are:

1. Catch the \Error from Container::get() and parse the message to see if it's a class not found. This also requires updating the PhpDumper to wrap any method instantiating a service in the same try/catch block (can be done through a proxy method though to avoid cluttering the generated class).
2. Analyze the backtrace from ClassNotFoundFatalErrorHandler to find out if we were trying to call a service with this id when the class not found error occurred.

Both solutions looks complex for this very specific DX regression, and moreover are still runtime exceptions, while it used to throw at compil time before :/

@ogizanagi what about adding a leading backslash and removing it when registering the service? i.e. forcing:

services:
    \bar: ~

but behind the scene remove the leading backslash so that $container->get(\bar::class) still works.

Alternatively we could make the class mandatory if no backslash if found at all in the service name:

services:
    bar: ~ # throw an error as not no `class` property has been found an `bar` is ambigus`

Thanks @theofidry for these suggestions.

what about adding a leading backslash and removing it when registering the service

Could be a solution. However, as mentioned earlier, I think we should keep the ability to do:

$container->register(\ExistingClassFromTheGlobalNamespace::class)

using the PHP format. So either we don't support the above, either that'll require moving the logic from passes to file loaders :/
Also, I don't really like transforming the service id behind the scene.

Alternatively we could make the class mandatory if no backslash if found at all in the service name

Yes, I think it's better to consider that registering a class from the global namespace this way is a limitation and throw. But I'm afraid everyone will disagree. 😄

I also prefer the second option, less magics and I think it's an reasonable limitation.

I fact, why not, with one more step: let's not map id to class when no namespace is found.
@ogizanagi I think you can try a PR doing that - enforcing the "class" attribute for global classes.
WDYT?

Sure, I'll do it.

@theofidry : It's already opened 😄 See #21453.
Thanks for your involvement. :)