With the 1.7.20-RC, the `Inline classes with gener...
# arrow
With the 1.7.20-RC, the
Inline classes with generic underlying type (experimental)
feature can improve some wrapper classes in Arrow, right? In a few places in the source, I think I recall seeing
data class Foo<T>(val value: T)
Yes, I think this might help but I've been wondering how much impact this actually has at runtime. Wouldn't this almost always imply boxing?
You'd probably have a better idea than I, but I had thought the appeal was that it let you avoid boxing and you wound up with inline value types after compilation I can check the bytecode today, it's a good question to be honest
If you've had any time to check the byte code I'd love to hear any findings 🙏 What bytecode analyser are you using btw? I've had some success with the
CFR Decompiler
based Kotlin IDEA plugin, but the IDEA integration seems a bit flaky 😅 I think the problem arises with something like
Either<String, String>
. If there is instance checking of runtime types involved, how can it be unboxed? 🤔 Since this is 90% of the usage in the generic cases of Arrow?
There is a new decompiler that supports more recent JVM features called Quiltflower that I use, it's really nice: https://github.com/QuiltMC/quiltflower
There's an IntelliJ plugin so you can use it from the IDE too 👍
Ah didn't know that, thanks for sharing! Curious to see how it'll compare to the one I used.
If I have time to look into it, and have some interesting findings I'll keep you posted.
I have tried to check
but for some reason, decompiling with Kotlin
seems to be using
Ah, is that due to the Kotlin plugin being backed into the IDEA now? I had some weird suggestions today that were based on
in a
project 😕 So the inferred types were using Definitely non-nullable types but the Kotlin version was not supporting it 😱
I guess I will need to actually compile this file instead of cheating and using decompile from IDE, haha