Hey hey! The Kotlin libraries team is considering ...

# stdlib

[Filipp Zhinkin]

Hey hey! The Kotlin libraries team is considering (but there's no final decision yet) stabilizing part of the Uuid API in 2.3, namely, the kotlin.uuid.Uuid class itself. Generator functions will remain experimental for now, and all new functions will be annotated as experimental too.
There were not a lot of feedback regarding the class itself, and it was experimental for a few releases, so it seems to be the time to declare it stable.
If you have any feedback on kotlin.uuid.Uuid, please don't hesitate sharing it. We would greatly appreciate any feedback. Thanks!

[CLOVIS]

I use it in a few projects, no issues so far

[mbonnin]

Would love to see this actually. We're using https://github.com/benasher44/uuid/, which is now archived and were hesitant to switch because of the experimental status in stdlib.

[andylamax]

I have started using Uuid all around, and the class itself has no issues on my side. All I need is a way to generate different versions of them, I think at the moment the stdlib only provides way of generating Uuid v4

[Filipp Zhinkin]

@andylamax which versions do you need to generate?

[andylamax]

I am interested in generating Uuid v7 as well as v4

[CLOVIS]

After reading the comments on https://youtrack.jetbrains.com/issue/KT-79871, I share their concerns that it should be Uuid.System.random() instead of just Uuid.random() to make them easier to test.

My use cases so far were mostly about logging and distributed tracing, which is "outside" the domain layer, so I didn't feel the need so far, but I do think it will be important.

[gildor]

I agree on this, I think stdlib should continue this approach for API as Clock and TimeSource
It's very powerful and flexible.

[Filipp Zhinkin]

I have some bad news regarding Uuid stabilization: we need to decide if we want to make it a value class at some point (and what would be a migration path in this case). That unlikely will happen before the deadline for 2.3.0, so I rescheduled stabilization to 2.4.0.
A corresponding issue: https://youtrack.jetbrains.com/issue/KT-81395

[mbonnin]

Slightly disappointed but that makes sense 👍 Thanks for the update!

[CLOVIS]

What will it be a value class of? It's 128 bits, right? So it would be 2 longs? Does that mean it will need to wait until multi-field value classes?

[Filipp Zhinkin]

@CLOVIS , that’s what I’m trying to figure out. Waiting for multi-field value classes is mot very desirable (we’re still waiting for Valhalla to stabilize unsigned arrays, and there are no sights of progress in the short term). But if we won’t wait for it, there should be a migration path in the future.

[CLOVIS]

Do you have an idea of what a migration path could look like? It seems to me that it's going to be a binary breaking change no matter what?

[Filipp Zhinkin]

No ideas at the moment, I’ll post all updates in the issue I shared above as soon as possible