This is the drawback of lazy loading choices, we cannot validate a submitted value without loading all choices.

I agree this is a kind of BC break though, we should find a way to deprecate this path, to enforce usage of proper constraints.

Hm.. defining a constraint kinda defeats laziness as well no? Cant we use loadChoicesForValues as an optimized check?

I dont think we should deprecate this behavior.

Hm.. defining a constraint kinda defeats laziness as well no?

Indeed, but without violating SRP.

I always liked choice type validating out-of-the-box for unknown choices. It's a nice safety net.

But you're right i never defined constraints for choice fields :)) i rely on the behavior of forms for this. Basically i choose between forms and the standalone validator per use-case, and mostly it's forms TBH.

It's at least weird to have different behavior between "choices" and "choice_loader".

But you're right i never defined constraints for choice fields

And this is why I think a deprecation is necessary to make it clear.

Relying on internal form behavior to validate data is wrong.

Okay.. as forms already integrates constraint validation. Why not auto register a choice constraint... isnt that plain convenient? I.e. normalize constraints option and prepend it.

IMO This is a good idea to consider when revamping type guessing.