Christophe Coevoet

> Better than that: I'm fine if ppl that use a FQCN identifier without returning a compatible instance get a SA warning. They would not. they might get a runtime...

The new phpdoc explicitly says "if the id looks like a class-string, the method MUST return an object of that type (or null)". That's definitely a stricter contract for the...

@nicolas-grekas interface implementations have to respect the contract defined in the interface. That's where the BC break is when making the interface stricter (and with this PR, we would end...

@nicolas-grekas the big difference is that in this case, the class that won't respect its interface is **our** class. So the faulty code would be ours.

Adding a decorator on a service that was registered using its class name as id (the default convention) is enough to make the service invalid regarding this new rule (the...

@nicolas-grekas if the code is written against the common interface, things indeed work. But SA will tell you that the type you get is `MyImplementation::class` and won't complain if I...

@lyrixx the static analyzer of the IDE can also read the dumped XML file. And I know that the Symfony plugin for PHPStorm is using that file for that purpose...

@ro0NL with our convention registering services using their concrete class as id, this would prevent us from ever decorating them (as the decorator will generally implement the same interface to...

@lyrixx what IDEs are doing is **also** static analysis. If you have a case where `ContainerInterface::get(ConcreteClass::class)` actually returns `DecoratorClass` (implementing the interface but not being a `ConcreteClass` and so not...

> I would also expect this could be used by `composer` internally to skip some API calls, as my understanding is currently it just queries each repository for each package...