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 userland Autoconfigure 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 the ResetInterface 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 are inherited. #39897 defines attributes that are not inherited.

That's THE 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 MyService implements MyServiceInterface {}

$class = new ReflectionClass(MyService::class);
// That's how RegisterAutoconfigureAttributesPass does it
$attributes = $class->getAttributes(Autoconfigure::class, \ReflectionAttribute::IS_INSTANCEOF);
// Whoopsie, empty array
var_dump($attributes);

Running PHP 8.0.6. Looks like the IS_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 class MyService won't list you the attributes on interface MyServiceInterface...

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

The announcement in blog says that Autoconfigure can be used to replace registerForAutoconfiguration for auto-tagging by interface.

So, I've tried this:

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

class ServiceA implements ServiceInterface {}
class ServiceB implements ServiceInterface {}

services:
    _defaults:
        autowire: true
        autoconfigure: true

    App\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.