The Target attribute only overrides the name used for named autowiring aliases (instead of using the parameter name). So we cannot throw an exception easily in such case. It would require making the usage of a named alias mandatory in some cases but not in others.

I just realized we have the same problem without Target:

public function __construct(LoggerInterface $someLogger)

It just feels more explicit when using the Target attribute and it's ignored when invalid. This issue came up when I was using Target incorrectly (I was using the service id as the name) and couldn't figure out what the problem was.

@kbond but we cannot throw an exception for such case where there is no $someLogger named autowiring alias instead of using the default autowired service. Otherwise, it makes the autowiring a lot harder to use by making named aliases mandatory for eveything.

Understood, this issue may very well be invalid or not possible/practical to fix. Just wanted to bring up a pain point I had.

I'm waiting to be on php 8.1 to test it but would this work?

namespace App;

enum Logger {
  case SomeLogger;
  
  public function alias(): string {
    // here convert this::class to the alias name automatically
  }
}

and then:

#[Target(Logger::SomeLogger->alias())]

and, if Target was an interface:

interface Target {
  public function targetName(): string;
}

#[\Attribute(\Attribute::TARGET_PARAMETER)]
enum Logger implements Target {
  case SomeLogger;
  
  public function targetName(): string {
    // here convert this::class to the alias name automatically
  }
}

so we could do #[Logger::SomeLogger]

This would feel über complex and serve no practical purpose to me @mathroc

Giving arguments a name is something that should remain local to a class.

About your concern @kbond, it is resolved if one doesn't define a generic autowiring alias (non-named one) next to named-ones.
That's the intended behavior to me. If you want an error, don't define that default non-named autow alias. Sometimes you're not in charge of defining the alias, I understand that. If you really care about that, you could try removing the generic alias you didn't create in a compiler pass maybe.

But as described, this is expected to me. No bug here.

If we're looking at this issue as a feature request, we could maybe add an argument to the attribute to explicitly exclude the generic alias from matching. I don't know how we would implement that. Feel free to dig and submit a PR :)

Got it, I'm going to leave alone for now. As Target has the same behavior as named method parameter aliases, you're right, there's nothing to "fix".