Very good idea! But I think it should be bundle.

@Strate
Well ... Drupal just uses the components of Symfony so bundles wouldn't be that good in case Drupal wants to reuse it.

Ok, it can be external library (with only one compiler pass, as I think), and separate bundle to integrate with symfony full stack apps.

@Strate Let's first talk about the problem at hand before talking about where/how to solve it.

I'm curious but missing the problem and I don't see a relation between the 2 examples.

As I see, this feature allows only passing service to method call, What about passing array of services to property or constructor's argument?

@dawehner could you paste (or link to) the code of the compiler pass implemented in Drupal, so that your code snippet is complete ? Seeing only the tags without the way they are processed does not make it easy to understand the solution you implemented.
And I recognize I don't want to spend time now searching it in the Drupal codebase myself as you probably know where the class is much better than me (not difficult given that I haven't looked at how Drupal is organizing its codebase)

Here ya go:
http://cgit.drupalcode.org/drupal/tree/core/lib/Drupal/Core/DependencyInjection/Compiler/TaggedHandlersPass.php

Any feedback about this? I like the idea because is a common use case of the compiler passes, with this we can reduce the code necessary to do something like this.

@Crell Thanks for implementation. This would be really great in standalone bundle.

Also it would be really nice to have this as an option. Though line to make it a bundle is thin.
Already done internally by:

• event dispatcher

services:
    app.exception_subscriber:
        class: AppBundle\EventSubscriber\ExceptionSubscriber
        tags:
            - { name: kernel.event_subscriber }

• console commands

services:
    app.command.my_command:
        class: AppBundle\Command\MyCommand
        tags:
            -  { name: console.command }

Externally by any tag system as written by @dosten and @dawehner

Why aren't all the breadcrumb builders registered as listeners to a build breadcrumb event? If a listener returns a breadcrumb, can't you just stop propagation and return? Or am I misunderstanding the purpose of the breadcrumb manager?

@patrick-mcdougle Well, of course this could work as well, BUT conceptually I think having a custom interface for generating breadcrumbs for example is better than an event.

But you're describing a custom dispatcher that has attached listeners, aren't you?

Now that we have support for custom tags in yaml (#21185) and maybe going to have true service locators (#21553), I think this could be great in the spirit of a lower entry bar.

Instead of having to know about compiler passes, based on #21553 it could be something like:

App\FooManager:
    arguments:
        - !service_locator [ !tagged 'foo']

While it increases complexity of the config like that, I do kinda like that feature. Though I'd love it to be lazy ;)

@iltar note that the example uses a !service_locator so it would be by nature :). If it was inside a !iterator the service would ends up with a RewindableGenerator, and if used as a direct argument then no laziness, just an array.

In Drupal 8 I really like how I don't need to create compiler passes for simple service collection. Would love it is this would also be a part of Symfony Framework (maybe something for the SensioFrameworkExtraBundle?).