👎 This looks a really weird hack for something that can be resolved easily.

@sstok The reason of this PR is that it looks strange to me to force users to have public services for an internal reason that might change in the future.
Maybe a better solution would be to make the services public instead of creating aliases.

Making them public would indeed be a better solution 👍

@sstok updated

Status: Works for me

The concept that is :) the tests seem to be broken.

@sstok I forgot some changes, the tests are fixed now.

Edit: The build fail on Appveyor is unrelated and seems to happen randomly.

I don't get this PR: if one did set a service as private, what a surprise that it becomes public automatically just because it's used somewhere, don't you think?

I'm also -1 on this, for the reason given by @nicolas-grekas

I'm closing it because two core members voted against it and provided compelling reasons, so we cannot merge it.

@Ener-Getick thanks anyway for submitting this contribution and hopefully next time we'll merge it.

@nicolas-grekas @stof marking a service as private means that it may not be accessible by the Container::get() method but there is no certitude so for me this attribute is mainly here to tell the developer "hey, you have to inject me, you should not fetch me from the container".
So for me an user wants his services to be marked as private in his configuration files but it doesn't matter how it is treated internally.

BTW we already set some service as public in a compiler pass for doctrine listeners : https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/DependencyInjection/CompilerPass/RegisterEventListenersAndSubscribersPass.php#L124

@jvasseur and IMO, this is a mistake.