does anybody know why we need this verbosity?
# getting-started
d
does anybody know why we need this verbosity?
e
https://github.com/Kotlin/KEEP/blob/master/notes/value-classes.md
The
@JvmInline
annotation makes it explicit that something special with this class is going on in JVM, and it enables us to support non-annotated value class in the future Valhalla JVM by compiling them using the capabilities of the Project Valhalla.
Why not the reverse? Why not a use a plain value class now, and add some
@Valhalla
value class in the future? The answer is that, so far, Valhalla promises to be the right way to implement value classes on JVM and Kotlin’s key design principle in choosing defaults is such that “the right thing”, the thing that developers will be using most of the time, should correspond to the shorter code. Ultimately, with the Project Valhalla, it will be the right thing to compile a default (non-annotated) value class with Valhalla, so it means that we must require an annotation now, with pre-Valhalla value classes, to avoid breaking changes for stable Kotlin libraries in the future.
d
why compiler can't check it automatically? if project valhalla exists. for example by jvm version used in project
and i don't think we will get valhalla on android in near 30 years. so this annotation is useless for android environment
e
it'll break binary compatibility if a
value class
in a library compiles to something now and a different thing in the future
d
we could config it with compiler param. so all value classes get this annotation implicitly. similar as we configure experimental features: with annotation or with compiler flags
a
I’m guessing that if the value class is compiled now, bundled, and loaded in a library, the annotation needs to stay so it can be differentiated between the newer value class and the current kotlin value class. A compiler flag would not work in this case. The annotation is retained (AnnotationRetention.RUNTIME) after compilation. I agree that it’s annoyingly ugly, I absolutely hate annotations, and I believe it will reduce its adoption. I am not sure why they couldn’t have just kept “inline class”, then no annotation would be needed. Eventually deprecate its usage in new code and use “value class” if/when this new value class ever happens. Not to mention that people writing Kotlin first targeting JS, or native, output might actually NOT add this annotation, breaking any cross compilation usage for the JVM.