skip to content

When two declarations with the same simple name are reachable (e.g., one via wildcard import, one in the same package), how does Kotlin resolve the reference, and how do you force a specific one?

level: seniorimportance: should knowfreq 35%

answer

  1. Same-package > explicit import > wildcard
  2. Two wildcards with same name => compile error
  3. Explicit import overrides wildcard
  4. Fix via explicit import, alias, or FQN
  5. Kotlin never picks ambiguous names arbitrarily

basics

~20 s

Kotlin prefers names in the same package and explicit (named) imports over wildcard imports. If there's a true ambiguity, it's a compile error, and you fix it by using an explicit import, an as alias, or a fully qualified name.

solid answer

~40 s

Name resolution follows a priority: a declaration in the **same package** and **explicit single-name imports** outrank **wildcard (star) imports**. So `import a.*` won't shadow a same-package `Foo` or an explicit `import b.Foo`. If two wildcard imports both bring a `Foo`, referencing `Foo` is **ambiguous → compile error**; the compiler does not pick arbitrarily. To disambiguate you: (1) add an explicit `import` for the one you want, (2) alias one with `import ... as`, or (3) use the **fully qualified name** at the use site (`a.Foo`). Explicit named imports also let you override a wildcard. This deterministic precedence (specific over wildcard, local over imported) avoids silent surprises and is why IDE 'optimize imports' tends to expand wildcards when collisions exist.

code

kotlin · 8 lines
kotlin
import com.a.*
import com.b.*
import com.a.Foo          // explicit beats both wildcards

fun use() {
    val x = Foo()          // com.a.Foo
    val y = com.b.Foo()    // FQN for the other one
}

go deeper

for a junior

May know aliasing exists but not the precedence rules.

for a middle

Knows explicit import beats wildcard and aliasing resolves clashes.

for a senior

Articulates the full precedence (local > explicit > wildcard) and that real ambiguity is a compile error, with three disambiguation tools.

for a principal

Sets team policy on wildcard usage, reasons about resolution stability as dependencies evolve, and weighs readability vs collision risk.

## The resolution priority When the same **simple name** could refer to multiple declarations, Kotlin resolves with this rough precedence (most specific wins): 1. **Local/declared in the same file or same package** as the use site. 2. **Explicit single-name imports** (`import a.Foo`). 3. **Wildcard/star imports** (`import a.*`). More specific sources **shadow** less specific ones. A same-package `Foo` or an explicit `import a.Foo` will take precedence over anything coming via `import b.*`. ## Genuine ambiguity = error, not a guess If two sources at the **same** precedence level provide the name—classically two wildcard imports each exporting `Foo`—the reference is **ambiguous and the code does not compile**. Kotlin refuses to pick arbitrarily, which prevents subtle bugs. ```kotlin import com.a.* // has Foo import com.b.* // also has Foo fun use() { val x = Foo() // ERROR: ambiguous } ``` ## Three ways to disambiguate 1. **Explicit import** the one you want (it outranks the wildcards): ```kotlin import com.a.* import com.b.* import com.a.Foo // now Foo means com.a.Foo ``` 2. **Alias** with `import ... as`: ```kotlin import com.a.Foo as AFoo import com.b.Foo as BFoo ``` 3. **Fully qualified name** at the call site (no import needed): ```kotlin val x = com.b.Foo() ``` ## Same-package wins over wildcard If the current file's package already declares `Foo`, then `import other.*` bringing another `Foo` does not shadow the local one; the local declaration is used. ## Why IDEs expand wildcards Because wildcard imports are the lowest-precedence and the usual source of collisions, 'Optimize Imports' may replace a `*` with explicit imports when an ambiguity would otherwise arise, keeping resolution unambiguous and stable as code evolves. ## Practical guidance Prefer explicit imports in code that mixes libraries with overlapping names; reserve wildcards for cohesive, low-collision packages. When in doubt, an FQN at the call site is the most local, surprise-free fix.

  • If your current package declares `Foo` and you also `import other.*` (which has `Foo`), which wins?
    The same-package `Foo` wins; the wildcard import does not shadow a local declaration.
  • Does an explicit import override a wildcard import for the same name?
    Yes. Explicit single-name imports are higher precedence than star imports, so they resolve the name deterministically.
  • What if you genuinely need both same-named types in one file?
    Alias at least one with `import ... as`, or reference one (or both) by fully qualified name at the call site.

saying these in an interview costs you the question

  • Saying Kotlin just picks the first import on ambiguity
  • Thinking wildcard imports can shadow same-package names
  • Claiming explicit imports lose to wildcards
  • Not knowing FQN at call site resolves clashes
  • Believing ambiguous wildcard collisions compile silently

context

resolving links…