is there any reason for the "auto discovered services only" actually?

Quick nitpick question: should the attribute be named#[Autoconfigure] or#[Autoconfigured]? Because the class is autoconfigured, it does not do any configuring itself.

The recently proposed#[Deprecated] attribute in PHP itself is in passive voice as well.

Because the class is autoconfigured, it does not do any configuring itself.

I feel like I missed explaining correctly how this works.Yes, this attribute declares a configuration rule for autoconfiguration.

IIUC, we now have 2 competing PRs here. As far as I know, it was decided that progress continues in#39897? Please correct me if I'm wrong, but otherwise this one should be closed I think.

@wouterj this one provides something else. Both should be merged to me in the end. This one before#39897 since it's ready and might be used by#39897 as explained in#39897 (comment)

/cc @symfony/mergers anyone?

As requested, I'll post some of my comment in the other PR (ref:#39897 (comment) ) here:

😃 What I like about this PR is that it reuses the autoconfigure system (using the Yaml file loader seems a bit hacky, but I'm surely not the one to make a decision about that).
😐 What I'm not so sure about is why there is a need to have a userlandAutoconfigure attribute. I personally don't see this need (especially if#39897 will make it, as that implements more specialized and nice userland attributes for this purpose).
I think such a generic attribute opens up a lot of misuse (e.g. in the other PR, it was shown that you can misuse attributes instead of implementing theResetInterface contract).
I feel like it couples attributes directly to DI (which e.g. a@required annotation explicitly avoids).
At last, by having both a generic attribute and more specific attributes (from#39897), we provide more than 1 solution for the same problem. How should we document this? What are the advantages of one over the other?

(using the Yaml file loader seems a bit hacky, but I'm surely not the one to make a decision about that).

What matters here is how one can describe something using an array data structure. YamlLoader does exactly this: turn arrays (from yaml) into actual calls. Here, we just reuse that logic, so that the same array-structures can also be used in attributes. E.g.:

#[Autoconfigure(    calls: ['setFoo' => ['the-args']])]

What I'm not so sure about is why there is a need to have a userland Autoconfigure attribute. I personally don't see this need

All ppl that use_instanceof or$container->registerForAutoconfiguration() have a need for this.
It allows telling to the DI engine how a definition should be autoconfigured, depending on the base types of the class it describes.

especially if#39897 will make it, as that implements more specialized and nice userland attributes for this purpose.

There is a critical difference with#39897: the attribute in this PR allows defining rules that areinherited.#39897 defines attributes that arenot inherited.

That'sTHE critical difference between both PRs, and why they fill a different need.

I think such a generic attribute opens up a lot of misuse (e.g. in the other PR, it was shown that you can misuse attributes instead of implementing the ResetInterface contract).

Can you clarify? To me, it looks like you're arguing against empowering ppl, which I'm sure you aren't.
I must miss something, or I just don't agree :)

I feel like it couples attributes directly to DI (which e.g. a@required annotation explicitly avoids).

I do not understand this "coupling" argument. To me, as I explained in#39776 (comment), there is zero difference between this PR,#39776 or#39897 in this regard.

Maybe you can help me understand what you mean with actual examples of when this "coupling" would happen?

At last, by having both a generic attribute and more specific attributes (from#39897), we provide more than 1 solution for the same problem. How should we document this? What are the advantages of one over the other?

See "the critical difference" I mention above.

How should we document this?

TL;DR of my previous comment:

• use#[Autoconfigure] on interfaces
• use[DependencyInjection] Autoconfigurable attributes #39897 on specific class-services

Note that these two lines are orthogonal.

@derrabus you've got it right. I agree about the doc.

This is a really cool feature, but I've just tried it and there seems to be an issue:

#[Autoconfigure(tags: ['some.tag'])]interface MyServiceInterface {}class MyServiceimplements MyServiceInterface {}$class =newReflectionClass(MyService::class);// That's how RegisterAutoconfigureAttributesPass does it$attributes =$class->getAttributes(Autoconfigure::class, \ReflectionAttribute::IS_INSTANCEOF);// Whoopsie, empty arrayvar_dump($attributes);

Running PHP 8.0.6. Looks like theIS_INSTANCEOF flag doesn't do what it is supposed to do.

You might have missed how this works. I can't really help because I don't know what you want todo, but of course, requesting the attributes on classMyService won't list you the attributes on interfaceMyServiceInterface...

@nicolas-grekas Yeah, I might've misunderstood something.

The announcement in blog says thatAutoconfigure can be used to replaceregisterForAutoconfiguration for auto-tagging by interface.

So, I've tried this:

#[Autoconfigure(tags: ['some.tag'])]interface ServiceInterface {}class ServiceAimplements ServiceInterface {}class ServiceBimplements ServiceInterface {}

services:_defaults:autowire:trueautoconfigure:trueApp\ServiceA:~App\ServiceB:~

And I was expecting both services to be tagged, but they are not.

Please open an issue if you think you found a bug, with a reproducer ideally.