add max uuid with all bits set.

[james-lawrence]

the opposite of the nil, its useful constant to have around.

i'll also note both should be better served by functions as global vars are mutable.

[cameracker]

Hi @james-lawrence , thanks for the suggestion. Could you elaborate a little on the use cases such a constant might provide? The nil UUID is useful for modeling uninitialized uuids for certain situations, but I'm not sure intuitively what a max UUID would grant.

Thanks!

[dylan-bourque]

Thinking about this a bit, a value with all bits set won't be valid for all UUID versions. One specific edge case is the 4 bits that contain the UUID version. Currently, the highest published version is 5 (with 6 and 7 in draft), which is 0101. Setting those other 2 bits would create a version 16, which doesn't exist.

[cameracker]

Thinking about this a little more... because there are version specific bits in the UUID, this would imply that we'd need a maximum per version, no?

[james-lawrence]

Its useful for comparisons, ranges, etc. The utility of it has nothing to do with the method you use to generate uuids (dont need a definition per version). Its useful in the same way 0,max int/neg,pos infinity (both numerically and for timestamps). I use it a ton for signalling that a set is finished for example. (Since its the largest possible value in lexographical order)

[james-lawrence]

You're thinking too hard about what it means per a arbitrary spec definition vs the utility it has in code ;).

[cameracker]

Thanks, but if we chose to ignore the upstream RFCs that define UUIDs to create random functionality, that would be deleterious to the functionality of this package.

Ill close this for now until there's additional interest. Thanks for the suggestion.

[dylan-bourque]

Your thinking too hard about what it means per a arbitrary spec definition vs the utility it has in code ;).

@james-lawrence for me it's about correctness, not utility. A value with all bits set is not a valid UUID. Also, version 1-5 UUIDs are not sortable, so the concept of a "max" value doesn't make sense. If you want/need a sentinel value use uuid.Nil, we don't need 2.

I just don't think this provides enough value to offset these inconsistencies it introduces.

[james-lawrence]

@dylan-bourque because you're viewing it through the lens of an arbitrary specification vs the actual values being generated. which are 128 bits and have a natural order. through this lens the max value I described is always correct no matter what uuid version you'd use. you can't generate a uuid larger than it.

@cameracker shrug your choice. thanks for listening.

[stevenaair]

@cameracker The current rev for RFC 4122 does define, in sec 5.4. Max UUID the following:

The Max UUID is special form of UUID that is specified to have all 128 bits set to 1

[cameracker]

@cameracker The current rev for RFC 4122 does define, in sec 5.4. Max UUID the following:

Wow! I totally missed that. Thank you very much for identifying that.

In that case, let's reopen and see if someone contributes :) I might throw it in there in a couple of weeks if I can dig up some time.

Things to keep in mind:

• This max UUID is an element of a draft specification, and we should clarify that it is experimental in the same way the other new UUID versions are and is subject for removal.
• We should double check the newer drafts still have this UUID. The linked draft there has been subsumed by another set of drafts.

[stevenaair]

• We should double check the newer drafts still have this UUID. The linked draft there has been subsumed by another set of drafts.

My bad. In the latest it's called "Omni uuid" in section 5.10. Omni UUID

[james-lawrence]

@cameracker contribute being like the definition of the variable that represents the max uuid?