Inline classes

[zarechenskiy]

Discussion of this proposal is held in this issue.

[dzharkov]

I'd say that this and the next item need clarification/some examples

[dzharkov]

I'd say, having undefined (recursively defined), e.g. generics with an upper bound equal to the class should be prohibited as well.
Or like this

inline class Id<T>(val x: T)
inline class A(val w: Id<A>)

[zarechenskiy]

Agree with restriction about recursively defined generics, thanks!

About the example, it's OK if we'll map Id<T> always to Any, I'll add a note about this

[dzharkov]

I wonder what happens with non-abstract interface methods.
Do we need to generate DefaultImpls in the case?

[dzharkov]

Here, "wrapper" term is a bit ambiguous since underlying type is a wrapper too :)

[zarechenskiy]

Agree, I think I'll replace it to a "Boxed type"

[dzharkov]

I'd also add some short description/examples of how these wrappers look like and where the methods' bodies are

[dzharkov]

BTW, are data inline classes allowed?

[zarechenskiy]

Well, they can be allowed... I'm not sure it makes sense, I'll add a note

[ZacSweers]

Related - is there a reason sealed classes can't support inlining as long as every subclass is also inline?

[LouisCAD]

@hzsweers Since there's no instance, how would you do is checks at runtime for use in a when or boolean expression?

[ZacSweers]

I would assume that they would work the same way is checks would work in normal use (I didn't see that listed as a listed caveat and assumed that meant it was supported, though admittedly I don't see how)

[LouisCAD]

I expect is check to not be supported on inline classes since they are identity-less, as said here

[zarechenskiy]

@LouisCAD Could you please elaborate? Type check should work the same as it works for primitives.
<expr> is InlineClassType
There are two options:

• type of expr is statically known to be an inline class type, then type check is trivial
• type of expr is statically unknown, so if it's actually of an inline class type then it should be boxed, therefore we do type check for boxed type

[LouisCAD]

@zarechenskiy Does that mean that anytime you put an inline class value to a reference that is higher in the class hierarchy (like Any), it is boxed, therefore, no longer inline for this usage?

[zarechenskiy]

@LouisCAD Yes, same as for primitives

[zarechenskiy]

We can discuss this problem in the issue. We had some design about what you are thinking :)
But it has too much restrictions, you can check opaque types in Scala, for example

[dzharkov]

So, we decided that fun foo(x: List<Name>) here it compiles to List<Name> from Java POV?

[zarechenskiy]

Yes, I'll add an example

[dzharkov]

I'd add a section about our arrays struggles

[gildor]

Why vararg is not allowed?

[gildor]

In general would be good to provide some basic comments about particular limitations/restrictons

[zarechenskiy]

Because it's not clear what type should it have. I'll add a section about arrays and then cover this question

[fvasco]

Hi @zarechenskiy, can you expose some clarification about List<T>, Array<T> and vararg T?

[gildor]

Why is it impossible to use var? Is it technical limitation or design decision?

[zarechenskiy]

I'd say it's both :)
Short answer is that because inline classes are identityless, they don't have state

[fvasco]

inline class Name(var s: String)

val name = Name("Alan")
name.s = "Bob"

Is name read-only or not?
How estimate the impact of change the Name.s property in a shared boxed type?

[Miha-x64]

Any problems with single-property class which violates other statements?

inline class Something(t: T) {
    init {
        // some init, checks
    }
    val value: U = transform(t)
}

[zarechenskiy]

@Miha-x64 This is the same as if we have private primary constructor + public secondary constructor, therefore we are going to prohibit such cases for now

[felipecsl]

Typo "a values"

[gildor]

How does this suppose to work?
Of course, you can create one inline class for each int, but it's not clear how this help with enum case.
Some kind enums based on inline classes or sealed would be really helpful tho
Are inline enums part of this proposal?

[zarechenskiy]

I believe inline enum classes deserve another proposal, but I'll put here a bit information about them

[LouisCAD]

Why would init block be prohibited? Isn't it where checks for the single value parameter would take place?

[cypressious]

You can't really check anything if at runtime the class isn't actually instantiated. Remember, it's inline after all.

[zarechenskiy]

Because of Java interop. We can't ensure execution of init block when value comes from Java. Consider this case:

// file: sample.kt
inline class Positive(val u: Int) {
    init { assert(0 < u) }
}

fun foo(p: Positive) {} // in JVM bytecode `p` is just `int`

// Java
...
SampleKt.foo(-10) // it's OK from Java POV

Also, this is the reason for public primary constructor requirement.
I'll write about this in the proposal

[LouisCAD]

@zarechenskiy Why not rule out giving the underlying value of an inline class in Java at compile time? Java would only be allowed to receive inline classes values as the underlying type, but only Kotlin would be allowed to invoke the inline "constructor".

[zarechenskiy]

I believe this question should be discussed in the issue.
I see here several options:

• we relax this requirement and have inconsistent behaviour
• we introduce some kind of assertions as for nullable values that come from Java
• use conversions for values that come from Java

Each of these options have cons, but it's worth to discuss it anyway

[Miha-x64]

It also makes sense to generate component1 function.

[fvasco]

I consider harmful expose the private value for the UInt example, or the component1 must have the same visibility of the value attribute

[zarechenskiy]

Could you please elaborate? Do you have a use case? Maybe it's a point to allow inline data classes

[Miha-x64]

Oh, you're right, auto component1 is useless.
Vice versa, it may be used by hand, for example:

inline class IntPair(private val value: Long) {
    operator fun component1() = value ushr 32
    operator fun component2() = value and 0xFFFFFFFF
}

[fvasco]

Inline class must have a single read-only (val) property as an underlying value, which is defined in primary constructor

There is an inconsistency

[zarechenskiy]

I'd say that this is an open question. We can support mutable inline classes if they will be used only with delegated properties. Currently we're looking for use cases

[fvasco]

Hi @zarechenskiy,
having a delegate with a backing field is interesting, however rules exceptions are harder to explain and understand.

[fvasco]

In the Kotlin code Name is a parameter type.
In Java code Name is a return type.
Name is a parameter or a return type?

[zarechenskiy]

Ah, indeed, Name and List<Name> should be used in return type position in Kotlin, thanks!

[fvasco]

Annotate each parameter using an explicit annotation with a boxed type can really improve code readability.
This code should be injected by compiler in the same manner of @Nullable annotation.

[artem-zinnatullin]

Awesome 👍 👍 👍

I have a draft of same KEEP, will do couple more rounds of review, so far looks fantastic!

[artem-zinnatullin]

Maybe explicitly clarify that inline class cannot extend other classes?

[artem-zinnatullin]

hm, that's pretty limiting, why is that?

Use-case: inside a class I want to use an inline class as an implementation detail, but I don't want other classes to know about it

[zarechenskiy]

Indeed, this is too limiting, thanks!
It's definitely can be a nested member, I'll think more about it

[artem-zinnatullin]

But why? Shouldn't it just do referential equality check on underlying object?

[LouisCAD]

@artem-zinnatullin That would be dangerous. Let's say two different inline classes both wrap an int which happens to have a value of 0. It would be considered equals reference while not representing the same thing at all?
Allowing reference equality would defeat the purpose of inline classes.

[artem-zinnatullin]

Good point 👍

I was thinking about it from Java perspective where I'll still be able to do reference comparison, I think it's fine to prohibit === from Kotlin side unless someone comes up with a good use-case.

[artem-zinnatullin]

I guess we need JS and Native interoperability sections as well :)

[zarechenskiy]

At some point we'll have it :)
For now, I'm going to put more information about common and expect/actual inline classes

[LouisCAD]

Why not allow init blocks and private constructors by enforcing boxed type when used from Java? This would work similarly to inline functions that are inline when invoked in Kotlin, but not when called from Java or the debugger.

[zarechenskiy]

Yes, this approach is nice, some kind of "closed world" for inline classes.
But note that inline functions cannot be virtual, while inline class types can be used everywhere. To enforce boxing for Java we'll have to duplicate methods, plus there are some issues with arrays (if we'll allow them, we'll have to box each element of an array on the border)

I'd say that we should think more about this approach, at least to understand our design space

[LouisCAD]

@zarechenskiy It should not duplicate methods, but rather, add a method that takes the boxed type that is visible in Java, which unboxes the value and call the static method that takes the unboxed value.
In case the defined method is also inline, the method with the boxed type would contain all the logic directly, since no method for the unboxed type would be generated (since they would all be inlined at call places).

[LouisCAD]

Why would open inline classes not be allowed?
Couldn't they be extended by other inline classes that would only be additional API wrappers that could add more restrictions and more functions?
Such restrictions added to an inline class extending another, open one could be:

• Narrowing down the underlying value to a child type of the one defined in the parent inline class
• Adding additional checks/logic to init blocks (if they are allowed)
• Overriding open methods from the parent inline class

[Miha-x64]

How runtime should resolve which subtype of inline class it deals with?

[LouisCAD]

@Miha-x64 The inline classes have a boxed (non inline) type for cases where you use generics or super types like Any, so either it can be done statically, without autoboxing, or it is boxed, so behaves like a regular class, until it reaches an auto-unboxing place again.

To make an analogy to something existing, it would work the same as primitive number types, who have their boxed types extending the Number class.

[Miha-x64]

@LouisCAD to assign Int value to a Number variable, you must box it, which eliminates the whole purpose of inline classes.

[LouisCAD]

@Miha-x64 Does boxing an Int somewhere in your program eliminates the whole purpose of primitive, non boxed integers in your whole program? I don't think so, and the same applies for inline classes.
If you always use them in ways that force autoboxing, then, yes, its pointless, but you'll usually not write autoboxing code everywhere.

[artem-zinnatullin]

Good point 👍

I was thinking about it from Java perspective where I'll still be able to do reference comparison, I think it's fine to prohibit === from Kotlin side unless someone comes up with a good use-case.

[artem-zinnatullin]

There is an interesting conflict with this section about equals/hashCode and implementing interfaces.

Let me quote:

Compiler will generate original equals method that is delegated to the typed version.

and

Inline class can implement only interfaces

Which means that comparing two different inline classes that use same underlying type and implement same interface can result in wrong behavior because of comparing underlying values which can be indeed equal.

Example:

interface Bytable {
    fun toBytes(): ByteArray
}

inline class UserId(private val id: String): Bytable {
    override fun toBytes(): ByteArray = "userId:$id".toByteArray()
}

inline class OrderId(private val id: String) : Bytable {
    override fun toBytes(): ByteArray = "orderId:$id".toByteArray()
}

fun f(bytable1: Bytable, bytable2: Bytable) {
    assert(bytable1 == bytable2)
}

fun test() {
    f(bytable1 = UserId("123"), bytable2 = OrderId("123"))
}

fun main(args: Array<String>) {
    test()
}

If you change inline classes to data classes, test will fail.
But I think it'll pass with inline classes which is interesting.

[alanfo]

I'm intrigued as to how exactly unsigned types will work under this proposal.

I can see how one could do something like this:

val u = UInt(42)

but how then would you access the value property if it's private or is the idea that u itself would be treated as the value?

Also, if you wanted to create a UInt that was greater than Int.MAX_VALUE what value would you present to the primary constructor? Presumably one would not be expected to work out the appropriate negative Int value corresponding to this so would Int literals be extended to permit higher values up to UInt.MAX_VALUE?

[Wasabi375]

I don't think number literals for unsigned values are part of this proposal, but I guess if they are implemented they need to allow for higher values than there signed parts. How else are you gonna get values for ULong. For UInt you could use a function converting a long. That being said, maybe you are doing something wrong if you have to hardcode numbers that big.

[artem-zinnatullin]

Wait, how will overridding toString(), hashCode() and equals() work?

inline class UserId(private val id: String) {
    override fun toString() = "UserId($id)"
}

fun test(userId: UserId) {
    System.out.println(userId) // ?
}

It'll require a wrapper class which is what inline class is trying to remove

[LouisCAD]

@artem-zinnatullin It'll be a static method that'll be called at invocation places, so still no additional allocation. If you put the inline class instance in a more generic type, it'll automatically be boxed (like Int and other primitives are), so it'll call the virtual version of toString() and alike methods.

[artem-zinnatullin]

How would System.out.println() or any other runtime-linked use-site know about any of these methods?

[ilya-g]

@artem-zinnatullin userId will be boxed into an instance of UserId wrapper class, then this object instance is being passed to println

[artem-zinnatullin]

aha, I guess it falls into nullable/platform-type case.

Still don't like this whole wrapping story, gotta think about it more.

[ricmf]

What is the reason for the single-value restriction?

[LouisCAD]

@ricmf It can only work on a single reference. If you have more than one property, you need two references, and that only works with a real enclosing instance (that is allocated, not inline). However, you can perfectly make an inline class enclosing a Pair if it makes sense.

[fvasco]

Maybe it is possible to use multiple values, I am thinking about it.
It should work like JPA Embeddable class , JVM escape analysis should avoid extra allocation, probably this is out of scope and we should wait for Valhalla.

The problem become tricky in presence of annotations.

[Xfel]

Shouldn't it be String?

[zarechenskiy]

No, here we know that null can be associated only with the type Name?, because underlying type of the inline class Name is a non-null reference type.

[zarechenskiy]

This is similar to what we have for IntArray/LongArray/...: IntArray? is just an array of primitive types