Hacker News new | ask | show | jobs
by pjmlp 2325 days ago
Nowadays there are trying to just get Kotlin anywhere and it remains to be seen how Valhalla and Panama will be usable from Kotlin.
1 comments

Panama would not seem to pose any problems as it's all code generation with MethodHandles/VarHandles. That should be directly callable from Kotlin.

As for Valhalla, it remains to be seen how it's usable from Java, let alone anything else. But Kotlin already has a form of value type (inline classes) so perhaps it'll be an extension of that.

Kotlin inline classes are heap allocated, they are just syntax sugar for regular classes.

One cannot just change their semantics after the fact.

Kotlin's inline classes (and Scala's AnyVal classes) are syntax sugar for static methods. The object itself is erased completely whenever possible (just like primitive values).
Which is not the same as the semantic meaning of doing stack allocations or being stored in registers.
The following:

    case class Foo(x: Int) extends AnyVal {
        def square: Int = x * x
    }
    val bar: Foo = Foo(5)
    println(bar.square) // => 25
Compiles down to (the moral equivalent of)

    object Foo {
        def square(x: Int): Int = x * x
    }
    val bar: Int = 5
    println(Foo.square(bar)) // => 25
If the inner value (x, in this case) can be stack-allocated or stored in registers then `Foo(x): Foo` will as well. `Foo(x): Bar` (where Bar is a supertype of Foo) will be autoboxed, but that also applies to primitive types (`5: Any` becomes a java.lang.Integer in memory).
Neither of those represent the same semantics of:

    inline class { ... ]
Which is guaranteed to be always stack-allocated or stored in registers, again you cannot retrofit semantics, specially when passing those classes to binary libraries.