Is it legal to declare same public `typealias` in ...

# announcements

[turansky]

Is it legal to declare same public typealias in different modules? Like this one:

package react

typealias FC<P> = FunctionalComponent<P>

[Zach Klippenstein (he/him) [MOD]]

In the same package as well?

[turansky]

Yes

[turansky]

It works, but it doesn't look legal :(

[andylamax]

should not be legal

[turansky]

Issue reported

[kqr]

if it is same same is it a problem?

[turansky]

Looks like bomb for me

[dmitriy.novozhilov]

This is common problem from JVM world. Imagine that you have such module structure and classes in it (pure java):

// MODULE: lib1
public class A {
    public void foo() {}
}

// MODULE: lib2
public class A {
    public void bar() {}
}

// MODULE: app (depends on lib1 and lib 2)
public class Main {
    public static void test(A a) {
        a.foo(); // (1)
        a.bar(); // (2)
    }
}

Which line ((1) or (2)) will be assumed as compile error? What happend on runtime if we comment errornous line?

[dmitriy.novozhilov]

Answer is simple: classpath order. JVM, java and kotlin lives in assumption that for each fully qualified name can be found only one class (or none). So on jmv (and javac, and kotlinc) problem of different classes with same fqn is resolved very simple: some fqn is resolved to first class which was found on classpath of compilation session/runtime
So even if we comment line (1) and it will be compiled successfully (because compilation classpath was lib2.jar;lib1.jar) there is no guarantee that this code won't throw NoSuchMethodError at runtime (where classpath can be lib1.jar;lib2.jar)

[dmitriy.novozhilov]

Unfortunately, there is no way to protect users from such kind of errors. Even if compiler will check that there are no clashes between names from compiled module and from dependencies or even between just names in dependencies (such check will cost a lot of performance), then there is no guarantee that on runtime there will be same versions of dependencies