Does anyone know if there’s any plans yet for kotl...

# stdlib

[mattinger]

Does anyone know if there’s any plans yet for kotlin to introduce a type of value class (i know that keyword exists, but it’s for a single value inline class) that’s kind of like a data class, but without the backward compatibliity issues? Ideally it would follow the same rules (must have at least 1 val/var in the constructor, etc…) but generate only toStrings, equals and hashCode. And more importantly NOT generate the copy and destructuring functions which can cause backward compatibility issues in libraries.

[kevin.cianfarini]

You may want to take a look at https://github.com/drewhamilton/Poko

[mattinger]

Thanks @kevin.cianfarini. I’m usually a little hestitant to use this sort of stuff as it leads to cascading dependencies on the version of kotlin compiler that. you are using. For instance, whenever we go to 1.8.x, we would need this plugin to be updated. That’s more an indictment on the lack of stability of the compiler plugin api to this point (compose suffers from the same issue)

[jw]

this is also a language feature not a stdlib feature, so #language-proposals is a better place to ask

[mattinger]

Thanks @jw I was trying to find the right channel for this (there’s a lot and when i searched for “lang” in the channels list i couldn’t find anything which was odd). I know you suggested “value” a few years ago when you wrote an article about data classes and their issues with backward compatiblity. But they used “value” for single value inline wrapper classes.

[jw]

yeah. well at the time Kotlin was still using inline to match Java, but then Java switched to value.

[mattinger]

I know this will sound c-ish/swift-ish, but i would advocate for struct

[jw]

could be record to match Java

[jw]

and, ideally, would compile down to records when possible

[ephemient]

we do have @JvmRecord

[jw]

Only for data classes, the precise thing we want to avoid

[Andrew O'Hara]

You can also try values4k. It doesn't require a compiler plugin, and gives you all the features you're looking for, but doesn't have the bytecode optimizations you would get from a @JvmInline value class.

[CLOVIS]

I believe I read somewhere that having destructuring functions based on naming instead of index is on the table.

For everything else you mentioned, please read https://github.com/Kotlin/KEEP/blob/master/notes/value-classes.md

Notably, it solves the copy issue by introducing copying as a language syntax instead of a function, so no backward compatibility issues.

[ephemient]

you can follow https://youtrack.jetbrains.com/issue/KT-19627 and https://youtrack.jetbrains.com/issue/KT-44653