I don't like the idea of the Pimple-like closures. It makes the behavior of the factory callable inconsistent between the case of a closure and the case of other type of callables.
Thus, it makes the code fragile as any bundle adding an argument in the service definition will break it (as the first argument will not be the container anymore).

Thus, using such closures will require marking the dependencies as public (as they are retrieved dynamically), and prevents the ContainerBuilder to perform any optimization on the service instantiation (as it is inside the closure). So using such Pimple-like closures has lots of drawbacks.

Pimple-like syntax has been removed.

Any chance to merge it in 2.6? ping @fabpot @stof

No, I still have too many questions/doubts to be able to merge this in a hurry, that's never a good idea.

The biggest problem of this PR is a coupling of ClosureDumperInterface with DependencyInjection component (it's bad as we need the same service in Routing configs, for instance). Probably we can move ClosureDumperInterface to the ExpressionLanguage. However, it wouldn't be perfect place as well.

I think I'm 👎 on this one. It adds a lot of complexity for very rare use cases that you can do another way.

I have to remind that initially it was done for the ArrayFileLoader, where closures look very nature comparing to the expression language. In our company we use Symfony DIC with such custom file loader and sometimes it would be really helpful for us.

Some use cases:

1. We have legacy code like singleton DB connection, i.e. Database::master(), Database::slave(), etc. Just for quick solution we would write

   <?php
   
   return [
       'services' => [
           'foo' => [
               'factory' => function () {
                   return new Foo(Database::master());
               },
               'class' => Foo::class,
           ]
       ]
   ];

   to avoid coupling with singleton Database class. Also we have legacy configs with ConfigLocator class. I can reuse config and don't hurt new code by singletons. We have really huge code base and sometimes it takes much work for refactoring.

2. The same motivation as described in http://symfony.com/doc/current/book/service_container.html#using-the-expression-language, i.e. it's much easier to make closure rather than creating separate class.

If you say that it's a "very rare case", you have to admit that you either don't want array file configs at all or expression language factory is a "very rare case" as well.

But it won't be merged in this way of course, because ClosureDumperInterface is tightly coupled with the DependencyInjection component, but I think it makes sense to raise this question again after #6129.

@unkind in your specific case, I would rather define services for your database connection (using your singleton getter as factory) and then inject the service in your foo service.

The issue when introducing the dumping of closures is that we add lots of complexity for that, and that we only allow dumping a subset of closures (anonymous functions which don't depend on their context at all)

The issue when introducing the dumping of closures is that we add lots of complexity for that, and that we only allow dumping a subset of closures (anonymous functions which don't depend on their context at all)

SuperClosure allows to detect context-dependent closures, so it's not real issue IMO, we can throw an exception to avoid them. Anyway, it looks weird to have context-dependent closures in such config file.

sure we can throw an exception in this case. But it means we don't support them, meaning we only support a subset of closures, not all closures.

Partial support is better than nothing in this case IMO.