I thought we would fully avoid storing instances from the container (i.e. remove the$validators property). Is there much interest to keep it? We did remove a similar one from the ServiceLocator class in#22029

I think keeping this internal cache is cheap and still worth it, but no strong opinion on this.

#22029 was motivated by the fact the memoization was useless when used with the symfony DI container and prevents from using properly non-shared services.
This one can be used with any PSR-11 implementation, which may or may not cache instances (unless it's specified as a PSR-11 requirement?) and we also create instances on the fly.

BTW,this makes me think this implementation can be moved to theValidator component instead of keeping it in theFrameworkBundle, as anyone should be able to use thisContainerConstraintValidatorFactory without using the framework bundle.

EDIT: The PSR-11 specifies:

Two successive calls to get with the same identifier SHOULD return the same value. However, depending on the implementor design and/or user configuration, different values might be returned, so user SHOULD NOT rely on getting the same value on 2 successive calls.

WDYT?

and we also create instances on the fly.

fair enough to me!

See#22905 about moving the class in the component (and keeping only one deprecation rather than the current three in 3.3)

On hold (waiting for 3.3 branch to be merged in upper branches to get#22905).

This can be closed

@chalasr : Not exactly, as the changelog is still missing an update. That's why I kept this opened in case it was not entirely done during the merge. Anyway, see#22926 then :)