if @SafeHtml requires a third-party sanitizer library, I suggest keeping it out of Symfony. A separate composer package can provide it, and have a requirement on the library it uses (instead of dealing with optional requirements).

regarding the CreditCardNumber alias, I would point you to the discussion on #26436, which seems to tell me we don't want to make it easier to discover that a credit card number is using luhn.

Regarding EAN, in Hibernate, this is just a Length constraint with only 2 possible allowed values for the length: https://github.com/hibernate/hibernate-validator/blob/eaa2cb6e45f95007c18297c2e4faea33e1c6b5ab/engine/src/main/java/org/hibernate/validator/internal/constraintvalidators/hv/EANValidator.java

About the EAN validator, the last digit is a checksum digit ... so there's something to validate there. See https://gist.github.com/damonjones/7566978

Well, but there could be indeed. But Hibernate does not, making this constraint quite useless.

@javiereguiluz

1- for the Date Validator, do we have always a interest to keep DateTimeValidator and DateValidator ? Should we keep just one ? DateValidator with format accepted by date() ?

2- Past, Future can be options of DateConstraint ? or should it be annotation using the validation of DateValidator ?

Well, these should not be options of the Date constraints, as these constraints make sense on a property holding a DateTime object too, only on properties holding a string representing a date (which is what the Date constraint is about).

so @past.... can only work if value is instance of DateTimeInterface ? and a format Date constraint which is YYYY-MM-DD ? no format option for this constraint ?
@stof

From https://docs.jboss.org/hibernate/stable/beanvalidation/api/javax/validation/constraints/Past.html i'd say yes, but maybe we can add a format option to these to allow strings.

edit: actually we can just create dates from strings as is: https://3v4l.org/vk0AO

@ro0NL I do not see your point regard to https://3v4l.org/vk0AO

well.. it shows we dont need a format option

@Past                 # datetime | string
@Date @Past           # string
@Type(DateTime) @Past # datetime

the first excepts any date string (e.g. https://3v4l.org/vk0AO), the second is narrowed to a formatted stirng

About the SafeHtml constraint, in my opinion, if you need to make sure that a string is safe from malicious code, it should be passed into a sanitizer anyway.

I don't see a common use case which would require to check first if it is already safe.

I have an Event entity and I wanted to use https://symfony.com/blog/new-in-symfony-3-4-improved-comparison-constraints to replace my own callback validator by @Assert\GreaterThan(propertyPath="startDate") in the endDate.

However, the callback also validates that startDate is a future date ... and that's something you can't do with an expression validator ... so I ended up keeping the callback validator.

In summary: the @Future or @FutureOrPresent asserts would have come in handy for me today :)

@javiereguiluz : Do you mean @Assert\GreaterThan("today") ? 😄 https://symfony.com/doc/current/reference/constraints/GreaterThan.html#comparing-dates

🤦‍♂️ Thanks Maxime 😊

This shouldn't have been closed since it's mentioning EAN (AKA GTIN), it's quite common for developers to work with "products" and having a dedicated validator for this specific identificator seems like something you'd want. It's not just length + checksum, it also has various flavors, etc.

Also that HtmlSanitizer is now proposed as new Symfony component (#44144) @SafeHtml constraint could be also included after :)