Now the only problem with it is that the values can be transformed in theAbstractComparisonValidator class, meaning that the message can be incoherent with what is actually passed by the developer to the constraint. I wonder if we should not add aprotected function supportsValue($value): bool in the abstract class to throw from here with the real value?

@fancyweb not sure i follow, the passed message still applies to numeric values. We get a different message/violation for type errors, like any other constraint does.

What I mean is that if my constraint is@DivisibleBy("+10 days") on a\DateTime value (totally not logical but still possible), the error message will beExpected argument of type "numeric", "\DateTime" given while I never provided a\DateTime instance in the first place. It was converted in theAbstractComparisonValidator class. The goal would be to have a better message with the initial passed value. Might not worth it though.

i see, IMHO that's a side effect we can live with yes.

Thank you@fancyweb.