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.
replyWell that depends on your luck, it could be a valid one about 1/16th of the time.
reply1/64, actually, because RFC-compliant (variant 1) UUIDv4 requires fixed values for both the version nibble and two bits of the variant nibble.
replyThe 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?
replyNice, thanks and I agree.
replyI 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.
replyNot 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 :)
replyWhat if I generate 16 random bytes and use that as id?
replyNo problem, just don't call it UUID
replyI 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.
replyI 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.
replyYou can say this for everything that has built-in support.
replySome 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.
reply