Question about value classes (I'm familiar with the old inline classes but it has been a while): I w...

# announcements

[Sam Garfinkel]

Question about value classes (I'm familiar with the old inline classes but it has been a while): I was under the impression value classes, like inline classes, behave with respect to the compiler like the wrapped class. So why is the following invalid?

@JvmInline
value class Bar(
   val foo: Foo
)

fun Foo.doSomething() {
}

ERROR HERE >>> Bar(Foo()).doSomething()

[Sam Garfinkel]

Nevermind seems type aliases are better for this use case.

[Sam Garfinkel]

Still I could have sworn that inline classes transparently inherited all of the behavior and could otherwise replace their wrapped type.

[louiscad]

The annotation is named JvmInline, not JvmValue

[Sam Garfinkel]

I think I made a mistake in the original question, in my code with JvmInline it still doesn’t seem to work.

[Sam Garfinkel]

Hmm maybe my memory is wrong about this point: https://kotlinlang.org/docs/inline-classes.html#inline-classes-vs-type-aliases

[Roukanken]

Yes: inline/value classes are meant for wrapping a class so it behaves *differently*; but they try to minimize performance impact of the wrapping.

Eg compiler will behave to it like a new class, with no real relation to wrapped one (except property ofc), but where it can, it will use just use the wrapped one so it doesn't actually need to do the wrapping.

[nkiesel]

I don't understand the question. Value/inline classes are supposed to create distinct types w/o runtime overhead. doSomething is only defined on Foo and not on Bar. So why do you expect Bar(Foo()).doSomething() to work?

[Sam Garfinkel]

@nkiesel My memory of how these worked was wrong.