UUID is just array of 16 bytes or two 64-bit ints. Generating UUIDv4 is like few lines of code. Is that a big deal? I don't think so.
UUID is just array of 16 bytes or two 64-bit ints. Generating UUIDv4 is like few lines of code. Is that a big deal? I don't think so.
16 random bytes is not a valid UUIDv4. I don’t think it needs to be in the standard library, but implementing the spec yourself is also not the right choice for 99% of cases.
Well that depends on your luck, it could be a valid one about 1/16th of the time.
1/64, actually, because RFC-compliant (variant 1) UUIDv4 requires fixed values for both the version nibble and two bits of the variant nibble.
The fact that we're discussing this at all is a reasonable argument for using a library function.
While it might be invalid, will most libraries choke if you give them a pseudo UUIDv4?
Nice, thanks and I agree.
I didn't say about 16 random bytes. But you're almost there. You generate 16 random bytes and perform few bitwise operations to set version and variant bits correctly.
Not that it matters. I don't even think that there's a single piece of software in the world which would actually care about these bits rather than treating the whole byte array as opaque thing.
Let's call it a valid UUIDv0 - all bits randomized including the version bits :)
What if I generate 16 random bytes and use that as id?
No problem, just don't call it UUID
I think it saves labor and eventual bug hunting to include these in a stdlib. We should not be expected to look up the UUIDv4 spec and make sure you’re following it correctly. This feels like exactly what reasonable encapsulation should be.
I had a similar thought a while back. Looking at the code for existing UUID projects, issues they fixed, and in some cases the CVEs, is a good way to form a different opinion.
You can say this for everything that has built-in support.
Some things are actually hard to implement. I'd spent a lot of time trying to implement concurrent hashmap, for example. UUID is not one of these things.