With the 1.7.20-RC, the `Inline classes with gener...
# arrow
g
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)
s
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?
g
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
s
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>
and
when
. 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?
g
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 👍
s
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.
g
I have tried to check
Either<R,E>
but for some reason, decompiling with Kotlin
1.7.20-RC
seems to be using
1.7.10
s
Ah, is that due to the Kotlin plugin being backed into the IDEA now? I had some weird suggestions today that were based on
1.7.x
in a
1.6.x
project 😕 So the inferred types were using Definitely non-nullable types but the Kotlin version was not supporting it 😱
g
I guess I will need to actually compile this file instead of cheating and using decompile from IDE, haha