What rules must hold for an `actual typealias` to legally satisfy an `expect class`? Give the constraints the compiler enforces.
answer
- platform type must already cover all members
- visibility at least as permissive
- constructors + companion must match
- RHS must be a concrete class, not an expect
- defaults only on expect side
basics
~20 sThe aliased platform type must already have everything the expect class promises — same members with matching signatures, matching visibility, and a companion if the expect declares one. The alias just renames that existing type.
solid answer
~40 s`actual typealias Foo = some.Platform.Type` is valid only when `Platform.Type` *already* provides a compatible counterpart for every member of `expect class Foo`. Concretely: each expected function/property must exist with a matching signature and at-least-as-visible visibility; constructors declared in the `expect` must exist; an `expect companion object` requires a matching companion (or static members the compiler can map); type parameters must line up. The right-hand side must be an actual *class/interface* type, not another expect. Default argument values are declared only on the `expect` side, never repeated. Because the alias adds no body, you cannot add or change members through it — if the platform type lacks something, you must use an `actual class` instead (often wrapping the platform type). The alias also must target a single concrete type, not a union or function type.
go deeper
Knows the platform type must roughly match the expect's members.
Enumerates concrete rules: member coverage, visibility, constructors, companion, generics.
Reasons about when coverage fails and the wrap-vs-alias trade-off, and the defaults-on-expect rule.
Considers contract evolution: adding an expect member can silently break an alias across all targets and how to manage that.
## What `actual typealias` is doing It **actualizes** an `expect class` by saying "the implementation is this already-existing platform type, under the `expect`'s name." Since a **typealias** adds no new declarations, the existing type must *itself* satisfy the contract. ## The constraints the compiler enforces - **Member coverage.** Every member declared in the `expect class` (functions, properties, nested classes the expect lists) must have a corresponding member on the aliased type with a **compatible signature** (parameter types, return type, `suspend` modifier, etc.). - **Visibility.** The actual member's visibility must be the same as, or more permissive than, the expected one. You can't satisfy a `public` expect with a `private` member. - **Constructors.** Constructors declared in the `expect class` must exist on the target type with matching parameter lists. - **Companion object.** If the `expect class` declares a `companion object` with members (e.g. a factory `randomUUID()`), the aliased type must provide matching companion/static members. - **Type parameters.** The number and bounds of generic type parameters must align between the `expect class` and the aliased declaration. - **Right-hand side is a real type.** It must point at a concrete class or interface — not another `expect`, not a functional type, not a union. - **No extra members via the alias.** A typealias cannot add, rename, or override members. If you need more than the platform type offers, you cannot use an alias. - **Default values live on `expect`.** Default parameter values are written only on the `expect` declaration and must not be repeated on the actual side. ## Example that compiles ```kotlin // commonMain expect class AtomicInt(initial: Int) { fun incrementAndGet(): Int fun get(): Int } // jvmMain — java.util.concurrent.atomic.AtomicInteger has matching members actual typealias AtomicInt = java.util.concurrent.atomic.AtomicInteger ``` ## Example that does NOT compile If `expect class AtomicInt` also declared `fun reset()` but `AtomicInteger` has no `reset()`, the alias fails — the platform type doesn't cover the contract. You'd switch to `actual class AtomicInt` and implement `reset()` yourself. ## Practical guidance Reach for the alias when the platform type is an exact superset of the expect surface; otherwise wrap it in an `actual class`.
- Can the aliased type have MORE members than the expect declares?Yes. The expect is a minimum contract. Extra members on the platform type are fine and are visible in platform-specific code, just not in common code.
- Why must default parameter values appear only on the expect side?Defaults are part of the common contract. Repeating them on the actual would risk divergence, so the compiler forbids redeclaring them in `actual`.
saying these in an interview costs you the question
- Saying you can add methods to the type through the alias
- Thinking visibility can be narrowed in the actual
- Forgetting the companion/static members must match
- Claiming you can alias to another `expect` type
- Repeating default arg values on the actual side