Open joewreschnig opened 3 years ago
As mentioned in https://github.com/google/uuid/pull/88#issuecomment-890388714 this does not address the ever-growing number of constructors in this package. It also means someone intending to use crypto/rand.Rand has to explicitly pass it in order to gain any performance benefit from this.
I didn't remove the original pool implementation because in the end that's a question of the module's specific commitment to its API compatibility rather than a technical one.
There is also the fact that it could sneakily be enabled by some transitive dependency. One of many reasons I chose to throw it out.
Combined with e.g.
bufio.Reader
this provides fast zero-allocation UUID generation if you do not consider heap memory particularly sensitive, without a global state or lock.I guess this is my proposal re. the discussion about #80/#86/#88. It's faster than both of them and the single new function opens up other optimization possibilities they don't, e.g. if you already have some pathological
[1000]UUID
you need to fill.I didn't remove the original pool implementation because in the end that's a question of the module's specific commitment to its API compatibility rather than a technical one.