Ashley Mannix

Hi @rogusdev :wave: I'd be keen to go catch up on some of the discussion around that. Those sections look like recommendations rather than requirements, so I think `uuid`'s current...

The test vector for UUIDv7 appears to use a fully random value for `rand_a` and `rand_b`: https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format-04#name-example-of-a-uuidv7-value I think we should consider supporting this, but don't think we need to...

We've currently actually got access to a counter in our `Timestamp` type, because that's where it gets stashed for `v1` and `v6` UUIDs. How does the following sound to you:...

This library already implements `v1` and `v6` versions and has some established API conventions that we need to remain consistency with. I think we should be able to support everything...

Thanks @sergeyprokhorenko :+1: Having a good reference implementation to point at will definitely be helpful

I've started working on an implementation over in #755 that supports respecting the counter value when constructing v7 UUIDs in a way that lets a caller decide how wide they...

> In both implementations in case the counter overflows, the timestamp field is incremented by 1 and the counter is reset to a random new start value (guard bit to...

In either case, `uuid` uses the `ClockSequence` trait for controlling how counters work so this behavior is configurable. If you use the `NoContext` type then you'll get fully random bytes....

Thanks for the PR @tbillington. Since the `bitcode` library is unstable we can't add support to `uuid` without also requiring the `uuid_unstable` rustflag be set too. The `zerocopy` support has...

Ah I just mean that the library is pre-1.0, so breaking changes are still expected. If the library does make breaking changes then we'll either need to make a breaking...