set the channel description: Discuss evolution of UUID (benasher44/uuid | https://youtrack.jetbrains.com/issue/KT-31880)

set the channel description: Discuss evolution of UUID ( https://youtrack.jetbrains.com/issue/KT-31880 | github.com/benasher44/uuid)

https://github.com/openjdk/jdk/pull/1444 give it some noise and maybe we get proper UUID parsing in the next JDK release.

Nice!!

There's no interest from anyone, all responses lately are from a stale bot. 😕

Maybe it's time for a KEEP. We have so many things in core, I don't understand why UUID cannot be one of them. Especially because a minimal impl without the variant/version/... stuff would be more than good enough for 99%

Noting a problem with multiplatform UUIDs that is painful and probably unsolvable: • JS really should use the built-in UUID generator in normal cases, and basically every UUID in JS is represented as a string. Fighting the JS platform is not fun. • Java UUIDs sort with signed longs, so sort order by string and sorter order directly differ. Between the two, you can't satisfy either platform. I think Java should probably be prioritized, but also adding complexity in JS increases binary size, which really matters in JS.

Different sort orders between platforms is a nightmare I'm dealing with right now in my UUID expect/actuals.

Hi everyone! Here is the proposal to introduce a multiplatform

Uuid

class into the stdlib: https://github.com/Kotlin/KEEP/issues/382 Please share your feedback in the GH issue.

@joseph_ivie > • JS really should use the built-in UUID generator in normal cases, and basically every UUID in JS is represented as a string. Fighting the JS platform is not fun. The proposed prototype uses Crypto.getRandomValues() to generate random bytes in Kotlin/JS. Do you think it can cause problems? > • Java UUIDs sort with signed longs, so sort order by string and sorter order directly differ. Indeed, it is a nasty problem to handle. This was one of the factors why we didn’t want to implement the

Comparable

interface. Please take a look: https://github.com/Kotlin/KEEP/blob/uuid/proposals/stdlib/uuid.md#comparable-interface

Glad to see the KEEP! Thanks! • Using Crypto.getRandomValues is certainly fine in terms of cryptographic strength. It's the potential inefficiencies of constantly pulling the UUID string representation out for interop that has me more concerned - I think there's a reason the built-in UUID generation function returns a string. I would hazard a guess that the optimizations for strings in JS engines are unbeatable by any created class object in JS. In addition, the JS ecosystem has fairly thoroughly standardized using RFC-encoded strings to represent UUIDS as far as I can tell. I've never even heard of a JS library that has a UUID that isn't a string. Better to use the ecosystem as intended the same way we do for the JVM - therefore, the JS implementation of UUID should be a typealias or value class around

String

. • UUID not being comparable is not great, but I guess I can't see an alternative thanks to the mis-implementation on the JVM. The primary purpose of a UUID in my mind is as a database key, which by definition means that UUIDs are sortable. Curse you, JVM!