uuid-rs / uuid

Generate and parse UUIDs.

Home Page:https://www.crates.io/crates/uuid

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Generate v5 & v3 UUIDs from Values that Implement `Hash`

azdle opened this issue · comments

Motivation
I've got a few different things that are shaped like https://doc.rust-lang.org/std/thread/struct.ThreadId.html, opaque identifiers that wrap a u64, that I'm using to generate reproducible unique IDs by name-spacing them with new_v5. These all implement Hash, it would be nice if I could just hand them to new_v5 or a 5v_from_hash or something.

Solution
I believe new_v5 and new_v3 could be changed from their current

fn new_v5(namespace: &Uuid, name: &[u8]) -> Uuid

to something like

fn new_v5<H: Hash>(namespace: &Uuid, name: &H) -> Uuid

Alternatives
I'm unsure if that could be a breaking change with how coercion are handled. If it is, new separate functions could be created instead.

Is it blocking?
Nope, I have a gross thing to extract the raw IDs for now, but it would be nice to not have to do that.

Hi @azdle 👋 This is a great suggestion 👍 I'd consider loosening that bound to be a minor change (the old API evolution RFC thinks so too). You're right that inference would break, like in this example:

let uuid = Uuid::new_v5(ns, name.as_ref());

but I think that's ok. These aren't really widely used methods and the proposed signature is better.

The ideal signature would probably simply be:

fn new_v5(namespace: &Uuid, name: impl Hash) -> Uuid

I looked into this, and it's unfortunately not as straight-forward as you'd hope. The standard hash APIs aren't really compatible with md5 or sha1, and when wrapped the hashing of slices produces different results than it previously did.

I think the best approach for now will be to add some examples to the project that show how you can convert something that implements Hash into a slice to pass to new_v5.

Just coming back through some triage. It looks like as nice as this would be a to do, we probably can't in a non-breaking way, so I'll go ahead and close this one for now. We might be able to revisit it in the future if things change.