you don't have a XML syntax for this

Also no tests.. it's a proof of concept :) but will do that.. wanted to propose it first.

Perhaps introduces a few things to discuss...

• may require tag attributes to be blank dont think this is needed as were only interested in collecting services at this point
• could support the priority attribute built in
• could leverage expression language for basic atribute support (in terms of filtering)
• may require something that does iterator_to_array to satisfy any array constraints not related to this PR

I think the latter is actually an important one...

Tagged scalars won't be supported in yaml before 4.0. So you can either use a different syntax, or you can whitelist just one tag using:

diff --git a/src/Symfony/Component/Yaml/Inline.php b/src/Symfony/Component/Yaml/Inline.php
index e8d5faa..82112f0 100644
--- a/src/Symfony/Component/Yaml/Inline.php
+++ b/src/Symfony/Component/Yaml/Inline.php
@@ -710,8 +710,10 @@ class Inline
 
         // Is followed by a scalar
         if (!isset($value[$nextOffset]) || !in_array($value[$nextOffset], array('[', '{'), true)) {
-            // Manage scalars in {@link self::evaluateScalar()}
-            return;
+            if (!in_array($tag, $whitelist = array('foo'))) {
+                // Manage scalars in {@link self::evaluateScalar()}
+                return;
+            }
         }
 
         // Built-in tags
diff --git a/src/Symfony/Component/Yaml/Parser.php b/src/Symfony/Component/Yaml/Parser.php
index 7b572e1..bbb1531 100644
--- a/src/Symfony/Component/Yaml/Parser.php
+++ b/src/Symfony/Component/Yaml/Parser.php
@@ -642,6 +642,8 @@ class Parser
             if ('' !== $matches['tag']) {
                 if ('!!binary' === $matches['tag']) {
                     return Inline::evaluateBinaryScalar($data);
+                } elseif (in_array($matches['tag'], $whitelist = array('!foo'))) {
+                    return new TaggedValue(substr($matches['tag'], 1), $data);
                 } elseif ('!' !== $matches['tag']) {
                     @trigger_error(sprintf('Using the custom tag "%s" for the value "%s" is deprecated since version 3.3. It will be replaced by an instance of %s in 4.0.', $matches['tag'], $data, TaggedValue::class), E_USER_DEPRECATED);
                 }

For XML, the syntax could be:

<service>
    <argument type="tagged-services" tag="foo" />
</service>

Above works currently (tagged scalar on a new line), so the syntax only improves as of 4.0.

perhaps to compromise it could allow !tagged_services [tagN, ...] as well.. to benefit from the allowed oneliner :) and multiple tag support of course.

Little update from my side;

• renamed to TaggedIteratorArgument
• yaml support !tagged_iterator tag-name
• xml support <argument/property type="tagged_iterator" tag="tag-name" />
• order tags by priority
• initial tests
• no multiple tag support, no automatic to array expansion

Open for any cosmetic changes / better naming etc :)

Could that be used to replace any existing passes? If yes, that'd be a good sign of the usefulness of it and should be done in the same PR if possible.

Technically yes. Now the priority attribute is handled it could replace some 🤞

Will look into that.

edit: from https://symfony.com/doc/current/service_container/tags.html looks like twig.extension is a candidate...

Furthermore if we ever allow to map a !iterator against an adder it could benefit from that by passing along tag attributes. Making everything available in runtime (sounds cool at least :))

@nicolas-grekas would it make sense to merge ServiceLocator and RewindableGenerator? Making IteratorArgument obsolete.. as we have something (ServiceLocatorArgument probably) that can be used for almost anything, i.e. typehints against iterable or ContainerInterface or array (with #22204).

That would end the iterator vs map thingy. And allows this PR to move forward with a single !tagged_service_locator again :) (we should expose !service_locator as well - #22649 (comment), and for #23454 it can be !service_closure).

Could that be used to replace any existing passes? If yes, that'd be a good sign of the usefulness of it and should be done in the same PR if possible.

I guess the problem is most rely on array API, so the auto expansion could actually help here to satisfy those and have easier migration.

Also thinks like https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Resources/config/session.xml#L59 can benefit i guess.

Dunno, we could try... :)

See https://github.com/ro0NL/symfony/commit/1360bab6154c9d29d27d42a9011a9300c8048afd for where im leaning to.. Argument\IteratorArg could become Argument\ServiceLocArg allowing to deprecate DI\ServiceLoc. Could work out, feel free to contrib :)

Basically i dont understand why we favor

!service { arguments: { k: '@ref' }, tags: [container.service_loc] }

over (simply)

!service_locator { k: '@ref' }
!service_locator [ '@ref' ] # keys are arbitrary

What !iterator does actually :) it has way better DX, dont you think? But maybe im missing why a tag is needed.

edit: if im correct it creates a new def+alias only to be inlined again afterwards.. lost me :)

@nicolas-grekas final proposal; im leaning to roll out my own yaml tag(s) otherwise.

Looking at my own usecases i could definitely use a tagged iterator as well as a tagged service locator *.

We can keep leveraging iterator arg and simply dont support tagged service locators, but to me thats half the feature. Not sure if worth it then.

So we could do !tagged_services tag-name; giving you an iterator. Or !tagged_services {tag: tag-name, index_by: id|class|tag-attr }; giving you a service locator.

*) Problem with tagged service locator is we cant get the full map, it's not iterable nor exposes getKeys. Which may be limiting, and therefor im not sure whats best way to introduce it in core; hence im leaning to roll out my own and keep things as is in core.

If you know the name of the tagged services, you don't need to tag them.
And of you don't know their name, you cannot "get" them from the service locator.
Which means to me only an iterator is useful... esp.since if you have an iterator, you can easily turn that into a map with iterator_to_array.
I also prefer tagged_services instead of tagged_iterator.
You did not deprecate any existing compiler pass, does that mean none can be replaced with this generic implem?
What's missing?

If you know the name of the tagged services, you don't need to tag them.
And of you don't know their name, you cannot "get" them from the service locator.

Yes, so true :) we dont need this 👍

if you have an iterator, you can easily turn that into a map with iterator_to_array.

But there's no key control, you'll just get numeric indexes. But lets forget about maps here ;-)

So, as is, we can at least cover twig.extension, kernel.cache_clear for sure. But we need to update some APIs from iterable to array, that be the cleanest. Or apply iterator_to_array out-of-the-box based on typehint; seems pragmatic but im not sure (well.. i was :P).. wdyt?

Tags like security.voter are a bit more difficult. And things like commands cannot even be done this way i guess. So it needs a per case decision.

For end users it may fit many more cases though.

apply iterator_to_array out-of-the-box based on typehint

I wouldn't recommend doing that :)

we can at least cover twig.extension, kernel.cache_clear

Let's see how it goes then

@nicolas-grekas this is hard :) and im not sure about the best approach.

I think there are 2 viable directions, given

method($mixed, array $array, iterable $iterable, ...$variadic)

Variant A - type based:

'$mixed': !tagged-services tag # pass a lazy iterable
'$array': !tagged-services tag # pass an array
'$iterable': !tagged-services tag # pass a lazy iterable
'$variadic': !tagged-services tag # pass a service + append subsequent services as arg

Variadic for numeric arg doesnt resolve subsequent arguments, as it implies subsequent args come from config (though not sure), i.e;

- [mixed]
- [array]
- [iterable]
- !tagged-services tag # pass a lazy iterable
- x # pass scalar for subsequent variadic

Variant B - tag based:

'$mixed': !tagged-services tag # pass an array
'$array': !tagged-services tag # pass an array
'$iterable': !tagged-services tag # pass an array
'$iterable': !iterator { values: !tagged-services tag } # pass a lazy iterable
'$variadic': !variadic { values: !tagged-services tag } # pass a service + append subsequent services as arg

I guess this variant allows for the same approach between numeric and named args.

So im leaning to tag based, but it requires refactoring here and there. Though type based looks nice.. i think explicitness is the way to go.

Basically we introduce a little DSL with !iterator !tagged-services foo.

@ro0NL could you rebase please?

Done.

edit: looking at tests.

Status: needs work. Cant get tests to work.

Need some help to both fix

DependencyInjection/Tests/Loader/PhpFileLoaderTest.php --filter testConfig 
DependencyInjection/Tests/Dumper/PhpDumperTest.php --filter testAddService

Now green fabbot failures are false-positives.
PR ready, still 👍 on my side.

Thank you @ro0NL.

@ro0NL @nicolas-grekas with this PR is it possible to use an alias as array index?

Nope :) just a sequence collection. We had a long debate about that.

You might infer alias/key from get_class($service) perhaps.

@ro0NL we from sulu (https://github.com/sulu/sulu) uses the tagged services and also aliased because we want to allow overriding this services. so this would be an awesome additional feature for us

Well done @ro0NL! :)

@ro0NL to clarify, can we use variadic's then?

nope, it injects an iterator. Variadics argument would not be compatible with IteratorArgument's lazy-loading.
Variadic argument would require creating multiple arguments in the definition, which is much more complex to implement here (this feature has nothing to do with autowiring btw, it does not inspect the signature).

Thanks for the clarification and explanation.