Eventually you'll get a value-based class that isn't inlined in the same way, ie the JVM code generation is different. A value-based class is one where equality is based on the underlying values in the class, and there is no concept of identity (so you can't use === to compare instances of a value-based class, only ==). If you omit the @JvmInline, you can still use the class in exactly the same way, but you won't get the under-the-covers inlining of the primitive value, auto boxing and unboxing, function name mangling etc. It will compile just like any other class. ETA: But for now non-inlined value classes aren't supported, so the annotation is required for JVM backends.
My Understanding is that value classes provided for all kotlin targets so, you need to annotate it with @JvmInline when you're writing code for Jvm backend (i.e Android)
It's required for now, and it limits the class to one property since that's the only way inlining like this is possible. It's because the JVM doesn't support value types yet (project Valhalla), with multiple properties, but the other platforms do.
Because there's no requirement for interoperability with other JVM languages (in particular, Java), a value class with a single property is automatically inlined in /JS and /Native. So you get the same performance advantages as you do with /JVM when annotated with the @JvmInline.
@@forresthopkinsa Not really. In those environments, as long as you know the code-generation strategy (inline references to the wrapped object), you can write code to interop with it. With JVM code generation, there are two mutually incompatible options: generate code compatible with Java value-based classes, or perform inlining for optimization. Since the code generated if different in each case, the annotation (or its absence) tells the compiler which variant to generate code for.
@@PeteC62 I guess in native side, there was no specific need as LLVM IR (which both Swift and Objective-C compiles to) has support for inline attribute. This would become a problem only if Kotlin Native uses a different compiler backend other than LLVM. Is my understanding correct?
So basically value classes help to write more explicit code without runtime overhead. Nice 🎉
It just goes to show the brilliance and hard work of the Kotlin language engineers! Feels awesome to be a part of such a nice ecosystem.
If you are wondering if everything is same between inline and value classes, why the fuss over it by having two things , then directly jump at 10:10
Finally I can understard why it starts with "value" keyword
to replace it to value
nice! to learn how useful it is, looking at go lang usage of type, scala's value classes and haskell's newtype would help
Thanke
is the `@JvmInline` annotation a must? What happens if you don't write it?
Eventually you'll get a value-based class that isn't inlined in the same way, ie the JVM code generation is different. A value-based class is one where equality is based on the underlying values in the class, and there is no concept of identity (so you can't use === to compare instances of a value-based class, only ==). If you omit the @JvmInline, you can still use the class in exactly the same way, but you won't get the under-the-covers inlining of the primitive value, auto boxing and unboxing, function name mangling etc. It will compile just like any other class.
ETA: But for now non-inlined value classes aren't supported, so the annotation is required for JVM backends.
My Understanding is that value classes provided for all kotlin targets so, you need to annotate it with @JvmInline when you're writing code for Jvm backend (i.e Android)
I’m not sure, but maybe this is for Java Interop, so if you’re using kotlin alone maybe you don’t need the annotation (?
It's required for now, and it limits the class to one property since that's the only way inlining like this is possible. It's because the JVM doesn't support value types yet (project Valhalla), with multiple properties, but the other platforms do.
Would be nice to know in what scenarios the compiler is unable to inline the value class.
Does the other video about the specific use cases when you would use value classes mentioned at the end already exist?
How is this handled on non-JVM platforms? Kotlin Native and / or JS?
Because there's no requirement for interoperability with other JVM languages (in particular, Java), a value class with a single property is automatically inlined in /JS and /Native. So you get the same performance advantages as you do with /JVM when annotated with the @JvmInline.
@@PeteC62 Wouldn't you encounter the same interoperability problems in Objective-C or JS though?
@@forresthopkinsa Not really. In those environments, as long as you know the code-generation strategy (inline references to the wrapped object), you can write code to interop with it. With JVM code generation, there are two mutually incompatible options: generate code compatible with Java value-based classes, or perform inlining for optimization. Since the code generated if different in each case, the annotation (or its absence) tells the compiler which variant to generate code for.
@@PeteC62 I guess in native side, there was no specific need as LLVM IR (which both Swift and Objective-C compiles to) has support for inline attribute. This would become a problem only if Kotlin Native uses a different compiler backend other than LLVM. Is my understanding correct?
And in the case of JS I wonder what happens. As far as I know JS has no inline support, so how is it done there?
Вы забыли добавить ссылку на видео Романа Елизарова про value-классы
Amazing, kinda like newtype in Haskell I think
Cool!
Which data types can be used with a Value Class?
Anything!
@@ben.woodworth Really?
very informative video...but it's seriously a little bit difficult to understand because of her accent :(
It's ok. Please start listen guys from India
use subtitles my friend