I really think there is no downside - this pattern is followed in many other places in Symfony. The lazy flag was added SO long ago, I think it was basically an old work around before we had the proper service locator solution.

I’d say, move forward with the deprecation and upgrade log stuff. Then we’ll probably need Nicolas to double check the implementation (it makes sense to me - but this is his area).

And thanks for making a PR - what an awesome surprise!

deprecation notice for thelazy attribute sounds good to me.

@weaverryan@chalasr but technically I removed the usage of the flag already 😄 So is a deprecation still correct? It should say something likeThe "lazy" attribute was removed in Symfony 4.2. Listeners are now always lazy by default.?

Or should we keep using the flag and remove it completely in 5.0? Although I think it does not have any BC breaks. Unless someone is weirdly relying on the fact that a service is eagerly instantiated 😋

I think going always lazy now is fine, the deprecation notice would only allow people to remove a dead tag attribute, and stop being triggered in 5.0. Not sure we had a similar case in the past so having an additional opinion would be good

By not triggering any depreciation for the unused "lazy" attribute, we're making it easier for e.g. bundles to support several major versions, isn't it? So should stay as is then IMHO.

@nicolas-grekas haha ok. I just added the deprecation 😄 But I can remove it again if needed. No problem.

So, would we keep that lazy flag (after it does nothing) forever? You’re right about compat, but keeping it forever seems odd.

We should just ignore it.

Documentation PR added, deprecation notice removed, tested with a real Symfony app.

Ready for a last round of reviews 😊

Thank you@dmaicher.