UUID API is confused

[kortschak]

The UUID API makes use of (visible) uint32 backing data, this is not currently endian-agnostic and can be interacted with by users directly.

• bytes representation of the UUID does not roundtrip: https://go.dev/play/p/bccbz_dNHAO: suggest maintaining order.
• uint32 elements can be interacted with by client code: https://go.dev/play/p/XZ6wRHlti3N: suggest making the type struct { [4]uint32 } if the uint32 approach is retained.
• endianness of data is mixed machine-endian and little-endian: this is only safe on little-endian architecture.

[aykevl]

1. Ah yes, that's true. We do need this for internal use, perhaps we can unexport this function to avoid confusion?
2. Good point, perhaps we should hide this (something like type UUID struct { uuid [4]uint32 }).
3. I don't see any code that relies on endianness?

[kortschak]

Thanks, @aykevl. Yeah, for the last one, I think you are correct. I spent some time yesterday trying to prove my intuitions and could not. I'll strike it.

[aykevl]

Feel free to make a PR to hide these implementation details :)

[kortschak]

The use of reversed order bytes looks to be completely entrenched in the API and its use, so I'm not sure what to do about that. As you say, we could unexport the Bytes method, but we can't replace it with the expected order, because that would cause additional confusion since the order would reverse. I thought about adding BytesBigEndian, but that's hideous.

[aykevl]

Just making it unexported would make sure it's a lot harder to misuse the API. That would help a lot already.