Deprecate \Drupal\Component\Uuid\Uuid in favor of \Symfony\Component\Validator\Constraints\UuidValidator

I don't believe this makes sense given you want potential UUID validation outside the context of constraints ... The UUID thing is just a generic library.

Having multiple copies of some code is not as bad as we thing it is, especially when its not business logic, as this much less likely will change.

Did some archeology and this was in fact never ever used in runtime code since its introduction all the way back in August 2011.

I don't feel strongly generally about deprecating or not, but contrary to #2 I do think it is somewhat problematic to have two different code paths lying around because they are not 100% compatible.
c5199ce3-f18d-8d80-a32b-2e8d5d216e64 , for example, will pass validation by Drupal's Uuid::isValid() but not by Symfony's UuidValidator because the 8 signifies the UUID version and there are only versions 1 through 5.

If we do deprecate Uuid::isValid(), I think it's OK for this sublety to remain in place, but if we do not deprecate it, I think we should explore making Uuid::isValid() use the Symfony validator internally, so that it's just the shorthand for the latter.

I think we should explore making Uuid::isValid() use the Symfony validator internally, so that it's just the shorthand for the latter.

I'd rather bite the bullet and get rid of it altogether by D9. The old logic allows for invalid UUIDs and serves no real purpose. Why not encourage people to use the Symfony version by explicitly marking our version as deprecated?

Nice research @tstoeckler!

I fear that adding a new dependency to the UUID component, might cause a flood of new discussions.

OK, so do you agree with deprecating then?

+1 from me, but I'm pretty sure you were asking Daniel :)

Maybe a possible alternative would be to motivate Symfony to extract the actual validation logic into its own component, so other people can use it easily. From my point of view the constrains are not meant to be used outside of the world of constrains.

That actually makes sense, seeing as we otherwise need a Constrain to pass to the validator. I've never patched Symfony before, where would one start to do such a thing? Or where would one raise a ticket for starters :)

They are really open to contributions and they merge things much quicker (time wise) than Drupal.
https://symfony.com/doc/current/contributing/code/index.html should describe it pretty well, how to contribute to Symfony.

Just FYI, core might not use it, but I know for example entity_embed does for validating embedded entities with their UUID. Deprecating is fine of course as long as the other thing can be used as an API directly, not just as a constraint.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!