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

# announcements

[LastExceed]

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

[András Bubics]

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.

[LastExceed]

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

[András Bubics]

Lambda signatures tend not to be accidentally compared, unlike primitives 🙂

[LastExceed]

oh ok now i get it

[András Bubics]

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.

[LastExceed]

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

[András Bubics]

what would that look like?

[LastExceed]

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

[András Bubics]

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

[András Bubics]

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

[LastExceed]

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

[András Bubics]

yarr, I just read the docs 😅

[András Bubics]

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

[Ray Eldath]

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<*, *> to AnyPredicate 😉 but it's just my experience, so it depends.

[Mike]

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.