Is it: 1. inline value class 2. inline class 3. value class ? Sounds like 1. is the official term b...

# naming

[mbonnin]

Is it:
1. inline value class
2. inline class
3. value class
?
Sounds like 1. is the official term but it's also very long and the doc mostly uses 2. but the code itself is mostly 3. Any preference?

[bod]

I vote 2 because of that doc you linked. (but yeah it's a bit unfortunate that the keyword is value)...

[mbonnin]

Yup

[ephemient]

Kotlin has https://github.com/Kotlin/KEEP/blob/master/notes/value-classes.md and https://github.com/Kotlin/KEEP/blob/master/proposals/inline-classes.md with substantial overlap but they are not entirely the same

[ephemient]

value classes are non-reference types. inline classes are (currently) the only possible user-defined value classes on JVM

[mbonnin]

So probably 2. is the most future proof because there might be other kinds of value classes later?

[mbonnin]

(but the keyword is value)

[ephemient]

only JVM has inline classes. they are simply value classes on other platform

[ephemient]

"value class" is what they are, "inline class" is an implementation strategy

[ephemient]

Valhalla also uses the name "value class", so thankfully the terminology will not diverge too much

[CLOVIS]

So probably 2. is the most future proof because there might be other kinds of value classes later?

It's almost certain that we'll get another type of value classes once Valhalla lands, which will probably be just value class without annotations. @JvmInline is a future proofing trick to avoid binary breaking changes once proper value classes land

[CLOVIS]

@ephemient do you know of a good source for info on how value classes are actually implemented on non-JVM platforms? Especially JS & Native, I haven't been enable to find reliable information