The current way would be to enable autoconfiguration for your interface with a tag and then use !tagged on that tag.

class Kernel extends \Symfony\Component\HttpKernel\Kernel
{
    protected function build(ContainerBuilder $container)
    {
        $container->registerForAutoconfiguration(SingleResolverInterface::class)
            ->addTag('app.single_resolver');
    }
}

ResolverCollector:
    calls:
        - ['addSingleResolvers', [!tagged app.single_resolver]]

The advantage of that is that you can opt-out of the autoconfiguration, in case you might want to create a class that implements SingleResolverInterface but shouldn't be injected into ResolverCollector.

note that for a local usage, you can also use _instanceof instead of registering your interface for autoconfiguration (in this case, the opt-out is moving the definition to a different service)

The goal is to

• use config only
• collect services from all configs, not just current one like _defaults and instanceof does

Neither of those 2 options meets this

use config only

I'm curious: What's the reason behind this requirement?

So basically, if you were able to extend the autoconfiguration from a YAML file, your requirements would be met?

See PR and post right in the top of description for this issue. It possible with tags, so the same should be with types.

So basically, if you were able to extend the autoconfiguration from a YAML file, your requirements would be met?

I'm not sure what you mean. But if I could be add own Yaml tag and configure it, it would be great.

I think this kind of binding is a very bad idea. Forcing a behavior based on the type prevents opting out from said behavior. Tags are exactly here to decouple behavior and types. Just use them.

Interface can declare type or behavior. I think, I did not need to declare interface with behavior to class if I do not want to use it.

I'm not sure what you mean.

I was referring to the php block in my previous comment. I you were able to configure the same thing inside a services.yml, your requirements would be met, correct?

Something like that (syntax debatable):

services:
    SingleResolverInterface:
        autoconfiguration:
            tags: [app.single_resolver]

    ResolverCollector:
        calls:
            - ['addSingleResolvers', [!tagged app.single_resolver]]

@derrabus That would be fine.

@nicolas-grekas Forcing a behavior based on the type prevents opting out from said behavior. Tags are exactly here to decouple behavior and types. Just use them.

Same applies for tags. Using this feature it optional and desired.

This is exactly what autoconfigure + tags + !tagged magic does in most applications, just in one clear spot.

Same applies for tags.

The sole purpose of tags is to make services discoverable for compiler passes. Tags only live in the context of the DIC compiler and there is nothing else you can do with them. Opting-out of a certain compiler pass would mean removing the tag.

But you cannot opt-out of a functionality tightly coupled to an interface.

@derrabus That topic is getting far away. I'd like to discussion close to what I asked if possible

I've updated the description to make it more clear.

As explained above, I'm 👎 , behavior and interfaces must be decoupled, that's what tags are for.

@derrabus your proposed syntax has an issue: this makes think that this new autoconfiguration applies only to the current file, while this is not possible with the current system. You should just use the existing _instanceof feature instead.

your proposed syntax has an issue

@stof I didn't want to propose a specific syntax, that snippet was just an example of how such a feature could look like. We can try to find a better one.

this makes think that this new autoconfiguration applies only to the current file

Okay, that was not what I've had in mind. Local autoconfiguration would be a bit pointless, I guess.

My point was that we currently cannot add autoconfigurations in config files. We have to do it programmatically at the moment. This is something we could change, imho. If someone comes up with good syntax scheme, that is. 😉

@nicolas-grekas As explained above, I'm -1tags are for.

You talked about forcing. I wrote there is none, since it's optional, like autowire and autoconfigure. You put it to config to use is or it's off by default.

behavior and interfaces must be decoupled, that's what tags are for.

Why? Also, this is not about behavior, but collecting services of specific type. How is that related to tags?

Any news on this issue? I'd love to use this feature and not having to create intermediary tags to get the same behavior.

Still 👎 for the given reasons on my side.

It should not be enforced, it should be only an option.

I am 👎 on having this in the core for the reasons that have been given. But it should be possible to build this as a third-party library, shouldn't it?

@xabbuh Agreed. I'd post a link to package if I didn't fail trying that :(. Could you share working code?

Closing as discussed. Thanks for the proposal anyway.

I miss working solution.

Actually, you need to not do this, it's a terrible idea (as explained above)...
(use $container->registerForAutoconfiguration() instead)