labels are wrong, my fault.

What's the point of the interface?

@unkind let you verify if ServiceLocator can provide services for class implementing ServiceSubscriberInterface.

And can be used for debugging.

probably @nicolas-grekas will bring more specific examples.

Thank for review, missed that it's supplementary for PsrContainerInterface.

let you verify if ServiceLocator can provide services for class implementing ServiceSubscriberInterface.

I mean not method by itself, but separated interface. I see the only implementation — ServiceLocator. Do you mind to provide example when type hinting against ServiceLocator is not possible/enough if you want to execute getProvidedServices()? Any other implementations?

@unkind what I described in th linked PR: to provide reflection on the inner of the locator.
This concern is legitimate for any PSR-11 container - ServiceLocator, but could also be implemented on our Container, etc.
It could help e.g generating useful message, allow iterating over services, etc. (any use case that reflection provides really.)

@mnapoli @moufmouf @Crell FYI here is an implementation of what we talked about recently in Paris :)

@nicolas-grekas Cool! I know I promised to write an article on this idea and I haven't had time to do it yet... this is still on my TODO list though!

I know the Symfony container is mostly used to store objects (which is not the case of all PSR-11 containers). Yet, some factories might return arrays of objects, or scalars. Do you think it might be worthwhile to add those cases to getProvidedServices() return types?

For instance: "string" maps to a string, "LoggerInterface[]" maps to an array of LoggerInterface...

"string" maps to a string

that's already the case here

"LoggerInterface[]" maps to an array of LoggerInterface

that'd need more information than we rely on in this implementation, but otherwise, yes (the current implementation is already compatible with it, it just won't ever return that :).)

@kejwmen would you be up to resume this PR? I'd suggest to rebase on top of master, and move the new interface in the Symfony\Contracts\Service namespace. WDYT?

@nicolas-grekas https://github.com/symfony/symfony/tree/master/src/Symfony/Contracts#design-principles is saying:

all contracts must have a proven implementation to enter this repository;

Doesn't this means that this cannot go directly in contracts ?

@stof correct, but we can still get closer to the point where this might be merged :)

@nicolas-grekas sure :)

@nicolas-grekas done.
What should I do about this failing test? Should I submit a separate PR with contracts or can we just ignore it?

@symfony/deciders I'm going to merge this PR soon: the feature it provides (reflecting what a container provides) is going to play nice with #30348.

Thank you @kejwmen.