Is there any drawbacks for using `value` class As ...

# kotlin-native

[Ankit Kumar]

Is there any drawbacks for using value class
As per my understanding it's helpful to make code more readable as many times using type as Int, String doesn't explain much about the context
so wrapping the types in value class makes it more readable
Also should we prefer typealias for these cases or value class is fine

[CLOVIS]

Type aliases are just aliases: they do nothing. They're nice when you have a really long time that you use often, for example:

typealias EitherFlow<E, T> = Flow<Either<E, T>>

Here, an EitherFlow<…> and a Flow<Either<…>> are the same thing. When one appears in the code, it's the same as if you wrote the other.

Value classes create a new type, that isn't the same as the wrapped value.

value class Password(val value: String) {

    // you can use the constructor to refuse invalid values
    init {
        require(value.length > 8) { "Password too short" }
    }

    // you can override how it is displayed (to ensure passwords don't appear in log files)
    override fun toString() = "[***]"
}

Here, a String and a Password aren't the same thing. You cannot assign a string to a password:

val a = "test"
val b: Password = a // doesn't compile

but you can ask the class to convert itself (and it may refuse by throwing an exception):

val a = "test"
val b: Password = Password(a) // ok, but may fail

Summary:
• use type aliases when you're giving a new name to an existing type, which makes no difference to the type itself or how it's used
• use value classes when you want to add things to an existing type to make it into something different
(also, this question should have been in #getting-started, not in #kotlin-native)

[Edoardo Luppi]

How are value classes treated in native? Are they optimized like in the JVM?

[CLOVIS]

I'm not an expert, but I think I remember people saying so, yes. If it's not the case yet, it's definitely planned for the future.

AFAIK, the Kotlin team had a prototype which could inline multi-field value classes on JS and Native, but they're not developing it further until Valhalla arrives

[Edoardo Luppi]

Damn, that would be a dream.
I'm not using value classes right now because of the additional wrapping in non-JVM platforms like JS.

[CLOVIS]

Value classes are inlined on JS already

[CLOVIS]

https://play.kotlinlang.org/#eyJ2ZXJzaW9uIjoiMS45LjEwIiwicGxhdGZvcm0iOiJqcy1pciIsImFyZ3[…]9cIilcbiAgICBcbiAgICBwcmludGxuKHAudG9TdHJpbmcoKSlcbn0ifQ==

[CLOVIS]

Look at the generated JS, there is no Password class, it's all just functions that take values as parameter

[Edoardo Luppi]

Oh cool! I was missing this one. Well good news

[Edoardo Luppi]

Ahh now I recall why I wasn't using them. Can't be JsExport-ed.
I was confusing the two topics.

[CLOVIS]

Ah, well, can't do anything about that.

[CLOVIS]

I mean, JS can only export symbols… by nature, value classes are not symbols…

[russhwolf]

A potential downside of inline classes is interop. For example, if you're calling into Kotlin/Native from Swift, it will just see the inner type and you lose the semantics of the class. So you may want to avoid inline classes at the language boundary. (I would guess that this is also the reason they can't be marked for JsExport)

[CLOVIS]

Yes, they can't be exported because the only thing you could realistically export is the underlying variable. However, value classes have constructors, and there is no way to force someone writing in another language to call the constructor before passing the value.

I guess defensively calling the constructor on all function calls (like how Kotlin checks for null parameters for all public functions) would maybe be a possibility? But of course, that has performance implications, and maybe semantic implications as well