With the 1.7.20-RC, the `Inline classes with generic underlying type (experimental)` feature can imp...

# arrow

[Gavin Ray]

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)

[simon.vergauwen]

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?

[Gavin Ray]

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

[simon.vergauwen]

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?

[Gavin Ray]

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

[Gavin Ray]

There's an IntelliJ plugin so you can use it from the IDE too 👍

[simon.vergauwen]

Ah didn't know that, thanks for sharing! Curious to see how it'll compare to the one I used.

[simon.vergauwen]

If I have time to look into it, and have some interesting findings I'll keep you posted.

[Gavin Ray]

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

[simon.vergauwen]

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 😱

[Gavin Ray]

I guess I will need to actually compile this file instead of cheating and using decompile from IDE, haha