You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the uuid v6+ draft, v6 UUIDs are just a rearrangement of v1 UUIDs. Being able to easily convert between them would be useful for updating anything that works with both rearranged and non-rearranged versions, plus providing an easy way to sort v1 UUIDs.
Hmm, I'd rather not add methods to Uuid itself that effectively become quiet no-ops depending on the version. In this case, I think we could add a method like fn node_id(&self) -> Option<[u8; 6]> that returns Some for v1 and v6 UUIDs, so that you could then write:
to get yourself a sortable UUID. It's a bit verbose, but keeps the scope of the library to constructing and deconstructing UUIDs, and not straying into grab-bag utility territory. That kind of functionality is useful, but it's difficult to gauge what's worth including.
Motivation
According to the uuid v6+ draft, v6 UUIDs are just a rearrangement of v1 UUIDs. Being able to easily convert between them would be useful for updating anything that works with both rearranged and non-rearranged versions, plus providing an easy way to sort v1 UUIDs.
time_low|time_mid|time_high_and_version|clk_seq_and_variant|node
time_high|time_mid|time_low_and_version|clk_seq_hi_res|clk_seq_low|node
Relates to #523
Solution
An API along the lines of the following would be nice:
Alternatives
This is currently possible by manually rearranging the bytes
The text was updated successfully, but these errors were encountered: