It seems weird to validate a numeric input using a regex. Functionally those constraints are Range so I’m not sure they’re needed. If they are, it probably would make more sense for them to be validated by the RangeValidator.

It seems weird to validate a numeric input using a regex. Functionally those constraints are Range so I’m not sure they’re needed. If they are, it probably would make more sense for them to be validated by the RangeValidator.

You're right that using Range makes sense for numeric validation — and we can use it to enforce geographic bounds. However, here’s why we combine it with a regex.
Range assumes you're working with actual floats or integers. It doesn't validate the format of input values like "+45.0", "0045.00", or "45,0" — all of which can be valid geographic coordinates but might be misinterpreted or bypass format expectations. Regex ensures proper structure (e.g. optional sign, correct decimal form), while Range enforces the numeric limits. So the two constraints are complementary.

Range assumes you're working with actual floats or integers

It also supports numeric strings, so it seems that it would solve all your use-cases?

I don't know if I'm in favor of this. I get the usage, but should we add new constraints every time we have a new format to validate without further validation besides a regex matching? This could be done with Assert\Regex() and a well named constant to hold the regex, isn't it?

Also on a side note: translations are added to the lowest maintained branch to ease maintainers work (and avoid conflicting IDs on upmerge). So if this one gets merged, it should be done in a separate PR.

I don't know if I'm in favor of this. I get the usage, but should we add new constraints every time we have a new format to validate without further validation besides a regex matching? This could be done with Assert\Regex() and a well named constant to hold the regex, isn't it?

Also on a side note: translations are added to the lowest maintained branch to ease maintainers work (and avoid conflicting IDs on upmerge). So if this one gets merged, it should be done in a separate PR.

true the Regex handle it, but we need to use the same regex everywhere in the code.i did this proposal to avoid duplication and for a better DX , readability ...

I still don’t understand why we’d want to validate a numeric input using a regex?