I ran into a situation where I am importing a top-property with a * import, and a type with the same name explicitly. I wanted to invoke a static method from the type, which resolved to a call on the property that I imported. At first I thought this is definitely a bug, but I realized that it is probably a subjective matter. There are two rules at play: * In Kotlin, properties and local variables take precedence over types/companion objects when resolving a function-with-receiver call. * Also, explicit imports take precedence over symbols imported with a

*

import. The reality is that the first rule seems to take priority over the second. I think it should be the other way around. What do you think?

I guess there are more than just the two rules. It makes sense that local variables take precedence over whatever else exists ("nearest" symbol in scope distance wins) Yet, I agree that b.GL should have precedence over a.GL. What if you switch the import statement, any change? Does b.GL has a

bindBuffer

function defined on the companion of b.GL ?

yes, I didn't mention that, it does indeed.

fair enough, does the GL in package

a

has a bindBuffer function? If so, then I would say that's the correct behaviour as it is nearer in terms of scoping

no `a.GL`'s type does not have

bindBuffer()

, and I would argue that its presence should not matter. what do you mean by nearer in terms of scoping exactly?

Your situation is a bit like:

class A {
    companion object {
        fun foo() {}
    }
}

class B 

fun foo() {
    val A = B()
    A.foo()
}

that is correct, and that is the behaviour exactly.

I agree on it's an edge case but still would argue it should behave the same way it behaves inside a function. The only thing which is not correct IMO is that the compiler gives up too early. That's the bug IMO but if this is how it is supposed to be, then I am with you, it is counter-intuitive that the explicit import is ignored

Yeah. I don't know if the compiler shouldn't "give up", I think calls should not be resolved in an ambiguous manner.

What happens if you import

b.GL.Companion as GL

In my case,

GL

is a java class with static functions.

no worries, surely good if you share your insights with Jetbrains