skip to content

What kinds of declarations can a Kotlin `import` statement bring into scope? Give examples beyond classes.

level: middleimportance: must knowfreq 60%

answer

  1. No `import static` needed in Kotlin
  2. Functions, properties, enum entries all importable
  3. Object/companion members importable
  4. Extensions need import to be callable
  5. Wildcard imports package members, not sub-packages

basics

~10 s

In Kotlin, import works for more than classes. You can import top-level functions, top-level properties, enum entries, object members, and even nested classes—anything with a fully qualified name.

solid answer

~30 s

Kotlin's `import` is broader than Java's. Besides classes and interfaces, you can directly import: top-level functions (`import com.acme.util.greet`), top-level properties/constants (`import com.acme.Config.MAX`), enum entries (`import Color.RED`), and members of objects/companion objects. You don't need Java's `import static`—a regular `import` covers callable and property members alike. Wildcard imports (`import com.acme.util.*`) bring in everything from a package or from an object/enum's members. This is possible because Kotlin treats top-level functions and properties as first-class members of a package, each with its own FQN. Extension functions are also imported this way, and importing them is what makes the extension callable in the current file.

code

kotlin · 5 lines
kotlin
import com.acme.Color.RED      // enum entry
import com.acme.util.greet     // top-level function
import com.acme.Config.TIMEOUT // object/const property

fun demo() = greet("x").also { println(RED); println(TIMEOUT) }

go deeper

for a junior

Knows you can import classes and roughly that functions can be imported too.

for a middle

Lists functions, properties, enum entries, object members, and extensions as importable.

for a senior

Explains the synthetic file class on JVM and how extension scope/import resolution works.

for a principal

Reasons about API ergonomics, wildcard policy, and how import surface affects public-API design and binary compatibility.

## Import is not class-only In Java, `import` brings in **types**, and you need `import static` for static members. **Kotlin unifies this**: a plain `import` can reference any named declaration by its **fully qualified name (FQN)**. ## What you can import - **Classes & interfaces**: `import com.acme.Order` - **Top-level functions**: `import com.acme.util.greet` - **Top-level properties / constants**: `import com.acme.Config.TIMEOUT` (and `const val` top-level) - **Enum entries**: `import com.acme.Color.RED` - **Object / companion members**: `import com.acme.Math.square` - **Extension functions/properties**: `import com.acme.ext.capitalizeWords` — importing makes the extension available as receiver-style call. ```kotlin // declarations.kt package com.acme.util fun greet(n: String) = "Hi $n" val VERSION = "1.0" fun String.shout() = uppercase() + "!" // usage.kt package app import com.acme.util.greet import com.acme.util.VERSION import com.acme.util.shout fun run() { println(greet("Ann")) // top-level fun println(VERSION) // top-level property println("hey".shout()) // extension fun made callable by import } ``` ## Why this works Kotlin compiles top-level functions/properties into a synthetic JVM class (e.g., `UtilKt`) but at the language level they are package members with their own FQNs, so the same `import` mechanism resolves them. ## Wildcard imports `import com.acme.util.*` imports all top-level members of that package. You can also do `import com.acme.Color.*` to bring every enum entry into scope. Wildcards do not import sub-packages recursively. ## Extension functions caveat An extension is only callable where it is **in scope**—usually via an explicit import. Without the import you must use its FQN, which for extensions isn't ergonomic, so importing is the norm.

  • Does importing a sub-package's wildcard pull in nested sub-packages?
    No. `import a.b.*` imports members of package a.b only; a.b.c is not included.
  • Why must extension functions be imported to be usable?
    Resolution of extensions is scope-based; the import (or same package) brings the extension into scope so the call site can find it on the receiver.

saying these in an interview costs you the question

  • Saying you need `import static` like Java
  • Claiming only classes can be imported
  • Believing wildcard imports recurse into sub-packages
  • Thinking extensions work without being in scope
  • Confusing enum entry import with importing the enum type

context

resolving links…