See #22200

What about an additional !variadic / VariadicArgument. In the same spirit as !iterator / IteratorArgument.

With tagged services it would look something like;

'$arg': !variadic !tagged-services tag

I was thinking about having injected tagged services without any extra code in services.yml (as long as autowire=true) or extra compiler pass.

That implies that we're able to compute a collection of TransportInterface.
But that's impossible, we don't do that anytime (and if autowiring does some sort of reflection, that's a deprecated feature, because it's a too fragile behavior).
Let's say we are able to create a list of such services, how would you compute it? The only algo I can think of is: do reflection on all defined services and create the list of all services that implement that interface.
That is extremely fragile also, and forbids any fine tuned behavior. There are many cases where that criteria (the interface some class implement) is not enough to be turned into a collection.
#22200 is a much more tailored solution, one that requires an explicit opt-in into such a behavior. A requirement to me.

Agree; to me the bare minimum is having extra config in services.yml, i dont see how it relates to autowiring at first.

The only "auto" thing i can think of is some typehint sniffing, ie technically we could this;

public function __construct(array $a, iterable $b, ...$c) { }

'$a': ['@service', '@other_service']
'$b': ['@service', '@other_service']
'$c': ['@service', '@other_service']

I think that's intuitive, though magic-ish. I believe this conflicts with @nicolas-grekas concern;

one that requires an explicit opt-in into such a behavior. A requirement to me.

But how i see it is; you configure a sequence; you ask for a sequence. Enough for DI to process :)

Just as a side note, if I remember well, chaining tags (in '$arg': !variadic !tagged-services tag) is not allowed.

Edit: it's indeed forbidden. See http://www.yaml.org/spec/1.2/spec.html#id2783797 for the reference.

as explained, I'm 👎