Inline classes

[zarechenskiy]

Discussion of the proposal:
https://github.com/Kotlin/KEEP/blob/master/proposals/inline-classes.md

[gabrielhuff]

This is an awesome idea and I can definitely see myself using this feature in different scenarios.

I just have a small question. From an implementation perspective, inline classes feel more like interfaces than actual classes (mainly due to their stateless nature).

The only reason I can think of that justifies the use of classes instead of interfaces is instantiation: instances can be "created" by calling the constructor. But I feel like there could be another mechanism to accomplish this.

What do you think?

[LouisCAD]

There was a discussion about allowing inline sealed class hierarchies in #103 (comment).

Since inline classes support autoboxing just like primitives, this could be possible to use inline sealed classes and do is checks in when or boolean expressions.
However, wouldn't it result in autoboxing most of the time (as is check is not possible on inlined value), defeating the purpose of making them inline?

[zarechenskiy]

@gabrielhuff Do you mean that inline classes are similar to something like "newtype" or "strict typealiases"? And they can be used like this:

inline type UInt = Int

fun test() {
    var x: UInt = 0
    x = 1 // type mismatch!
}

?

It's interesting, but we believe that current form to declare members/types is suited for us better

[zarechenskiy]

@LouisCAD
Yes, we can imagine inline sealed classes like this:

inline sealed class Base
inline class Foo(val s: String) : Base()
inline class Bar(val i: Int) : Base()

All subclasses must have different runtime underlying representation.

And you're right that in current design autoboxing will occur even on the simplest cases:

fun box(b: Base) {}

fun test() {
  box(Foo("")) // boxing
}

Basically, yes, currently this is a major reason to prohibit inline sealed classes for now

[udalov]

I wonder if @InlineOnly inline classes were discussed? That is, classes which are always inlined, and an attempt to box an instance of which would cause a compilation error. In theory, their metadata could be stored more compactly than in the .class file, and the whole .class file is not needed for them at all.

[zarechenskiy]

@udalov Interesting! In other case, for @InlineOnly underlying representation could always be used:

@InlineOnly
inline class Name(val s: String)

fun foo(n: Any) {}
...
foo(Name("K") // no boxing

Here .class file also is not needed

[gildor]

I think @InlineOnly semantics would be very helpful. you don't worry about an accident boxing and always has close to zero overhead.

[artem-zinnatullin]

Current spec seems to not cover annotations on inline classes.

It seems that annotations are pretty much useless since class gets erased after compilation.

Moreover they might be even dangerous as they might trick user into thinking that they'll make difference:

inline class UserId(@SerializedName("user_id") private val id: String)

However I guess you could give compiler plugins a chance to introspect them (which might be very useful).

WDYT?

[sakno]

Due to nature of inline class it should be passed by value. If so, this feature intersects with const data class feature and upcoming value types proposed by project Valhalla as part of Java 10.

[RaisedByTheInternet]

Since inline classes can't have init blocks, how can we do validation?

For example, suppose I create a Username class:

inline class Username(private val value: String)

And I want to throw an exception at run time if somebody tries to create a Username that contains spaces:

Username("Invalid Username") // error

Will this be possible?

[gildor]

@RaisedByTheInternet This is also true for Data classes.
Maybe private constructor + factory function can help with that because there is no such problem as with data class that also exposes copy method

[zarechenskiy]

@artem-zinnatullin Yes, annotations on underlying value should be prohibited, thanks for pointing this out! Moreover, there might be inconsistent behaviour for boxed/unboxed representation.

It's hard to say about compiler plugins for now, could you please elaborate more about use cases?

[zarechenskiy]

@sakno As I see, const data classes can use very restrictive set of types as an underlying value to ensure constant hashCode/toString. So, goals and motivation of inline classes are different.

Yes, we're closely watching the project Valhalla and probably will try to use their mechanism for value/inline classes in future