(as I recently found out) inner type aliases capture the type arguments of the class which saves you a lot of typing:

class Foo<T> {
    typealias Source = (T) -> String

    fun foo(source: Source) { //no 'T' required here
    }
}

Of cause, Java will be able to call methods with type aliases in signatures. Problem is that any assumptions you make based on the fact that type aliases are "new types" can be (and will be) broken by Java code.

BTW, this also is sort of an answer to questions "why no union types?" and "why intersection types are non-denotable?"

Regarding extension functions - good point. BTW, https://youtrack.jetbrains.com/issue/KT-1560

issue created: https://youtrack.jetbrains.com/issue/KT-13244

There are things already that give type safety in Kotlin but don’t in Java interop, and that’s fine. -> Not sure I accept argument about Java interop. Especially with Value classes, as far as I understand they will be compiled down to original types because of 0-cost abstraction which again makes Java interop “unsafe” but keeps Kotlin code type safe. What about:

Maybe better deprecate adding extension functions and properties to typealiases to not break user expectation?

Well, it looks very much like an expectation based on a wrong assumption. Sorry, but it is not compelling enough to deprecate a feature that can be used correctly. And it looks like diagnostic for extension shadowed by member can alleviate the pain (if there is one).

Well, it looks very much like an expectation based on a wrong assumption.

Please elaborate on that. You want to say that

value class UserId: String

won’t be visible as

String

in Java?

Yes, it will be a different class. Note that design details for "value classes" depend on the (intermediate) results of project Valhalla.

now that I think about it: because type classes will work based on Valhalla, will they require Java 9?

(so, no Android?)

Hm, but if you want introduce value classes in 1.2 how would you do 0-cost without Valhalla?

Under 1.2+ I meant 1.2 or later.

We do not know yet. This is a sort of a compromise, as you can see: type safety in mixed-language projects vs efficiency on Android.

It is quite likely that "efficiency on Android" can win 🙂

ok, I see, thanks!

getting VerifyError with coroutines on Dalvik 😞

creating repro right now

DALVIK shakes fist in the air with anger

😂

yeah, let's just set minSdk to 24, it's not like anyone is using Kitkat anyway /s

also got VerifyError on ART, but unable to reproduce it in a sample project

hm, I can't reproduce it, either

that's why we can't have nice things

got it

here's the repro https://github.com/cypressious/KotlinTypeAliasIcBug/tree/coroutine_verifyerror

now that's a weird one. I have a class. if I change a lambda to a bound callable reference in one place, at a complete different place in that class, a (non-bound) method reference doesn't compile anymore because a generic type can't be inferred

ah! an import gets deleted. but why?

ah, it has nothing to do with the bound callable reference, it was just a modification that triggered the import clean up.