A modern programming language that makes developers happier.

kotlinlang

when should i use a type alias, when an inline class and when just the underlying type?

example:
i'm developing something like an instant messager and each message has a unique ID (which at the end of the day is just a `Long`) and i figured it might be worth using a typealias or inline class to clarify that using this number for e.g. multiplication makes no sense.

if possible, I am looking for a generalized answer so I know how to make this decision myself in the future

It's easy to be bitten using `typealias`, especially if you expect the compiler to help you avoid simple errors (like accidentally comparing incomparable types).

I like to restrict `typealias` to things like lambda signatures, where they reduce verbosity, but don't give false confidence. It can also help as a stepping stone for refactoring.

i'm a bit confused, your second sentence seems to give examples for the exact opposite of what your first sentence says

Lambda signatures tend not to be accidentally compared, unlike primitives :slightly_smiling_face:

As an OO concept, modelling an ID as a class has a lot of merit. It means you can change how it works underneath without having to change all the call sites. And you get some compiler help.

so you'd opt for the inline class in my use case ?

each message has a property "id" of type "MessageID" which would be an inline class with the underlying type "Long"

(I'm not familiar with many experimental features atm, sorry)

mm yeah, that seems like a good solution :slightly_smiling_face: I haven't used it, though, so there may be issues I'm unaware of

an instance of an inline class is is basically an instance of the underlying type with extension functions. for this reason an inline class must have exactly one primary constructor parameter, because that parameter will be what the inline class compiles to

Hope you get some more input, I mostly came in to give hints about typealias pitfalls . . . I'm interested to hear other people's recommendations

well, also think seems inline class is good for your case.

very agree to the point about "restrict `typealias`  to lambda signature". I use `typeclias`  mostly for alias lambda signature and generic type, like shorten `Predicate&lt;*, *&gt;`  to `AnyPredicate`  :wink:  but it's just my experience, so it depends.

`inline class` is definitely intended for the MessageId case. Providing stronger typing while minimizing/eliminating the overhead incurred creating, and deleting a bunch of classes. As the name implies, the compiler will attempt to inline the class to the type in bytecode. Similar to what the Java compiler already does for Integer etc types.

But as noted, it's still in experimental stages. For Kotlin, that generally means that the usage or implementation is subject to change, and not that it's an unstable feature. Still, you have to explicitly let the compiler know you're ok with taking on this risk/tech debt.