Where exactly must a loop label be declared in Kotlin, and what are the syntax rules for declaring and referencing it? Show a valid and an invalid placement.
answer
- Declare: name@ before the loop
- Reference: break@name (keyword first, @name)
- Label must enclose the jump lexically
- Unresolved label = compile error
- Labels have their own namespace
basics
~20 sWrite the label as a name followed by @ directly in front of the loop, like loop@ for (...). To use it, write break@loop or continue@loop with the @ before the name. The label must come before the loop, not after.
solid answer
~50 sA Kotlin label is an identifier immediately followed by `@`, placed **before** the loop expression it names: `outer@ for (...)`, `rows@ while (...)`. The reference form swaps the order — the keyword first, then `@name`: `break@outer`, `continue@rows`. Any valid identifier works as a label name; it lives in a separate namespace from variables, so a label and a variable can share a name (though that's poor style). You can only reference a label that is in scope — i.e. one declared on a loop that lexically encloses the jump. Referencing an undeclared or out-of-scope label is a compile error. A label must be attached to a loop (or other labelable expression) — you cannot float a bare `name@` with nothing after it. Labels are most useful on the outer loop of a nested structure; labeling the innermost loop is legal but redundant since plain break/continue already target it.
go deeper
Recognizes the name@ for(...) declaration and break@name usage.
States the declaration-vs-reference @ asymmetry and that the target must lexically enclose the jump.
Explains the label namespace and that an out-of-scope label is a compile error, not a runtime one.
Advises on naming conventions and when labeled loops should be replaced by extracted functions for maintainability.
## Declaration syntax A label is **`identifier` + `@`** placed *immediately before* the labeled expression: ```kotlin loop@ for (i in 1..10) { /* ... */ } rows@ while (hasNext()) { /* ... */ } scan@ do { /* ... */ } while (cond) ``` Key points: - The `@` is a **suffix** on the label name in the declaration: `name@`. - The label sits **before** the loop keyword (`for`/`while`/`do`). - Whitespace between `name@` and the loop is allowed. ## Reference syntax When jumping, the `@` becomes a **prefix** joined to the name, after the keyword: ```kotlin break@loop continue@rows ``` So declaration is `name@ for(...)` and use is `break@name`. This asymmetry trips people up. ## Scope rules - A label is visible to `break@`/`continue@` only inside the body of the loop it labels. - You may only target a loop that **lexically encloses** the jump. - Targeting a label that isn't declared, or is on a sibling/already-finished loop, is a **compile error** (`unresolved label`). ```kotlin outer@ for (i in 1..3) { for (j in 1..3) { break@outer // OK: outer encloses this } } // break@outer here would NOT compile: out of scope ``` ## Invalid placement example ```kotlin // WRONG: label after the loop / detached for (i in 1..3) outer@ { } // not how you name a loop ``` The correct form names the loop up front: `outer@ for (i in 1..3) { }`. ## Namespace note Labels occupy their own namespace, so `x@ for (x in 1..3)` compiles, but reusing the variable name as a label hurts readability — prefer descriptive label names like `outer@`, `rows@`, `search@`. ## Redundant labeling Labeling the innermost loop adds nothing: plain `break`/`continue` already act there. Labels earn their keep when you must reach an **outer** loop.
- Can a label name match a variable name in the same scope?Yes — labels live in a separate namespace, so `x@ for (x in ...)` compiles. It's legal but discouraged for readability.
- What error do you get referencing a label that isn't in scope?A compile error such as 'unresolved label' / 'unresolved reference'; the code does not build.
saying these in an interview costs you the question
- Putting the label after the loop or after the brace
- Writing the reference as `@break loop` or `loop@break`
- Thinking labels are dynamically scoped rather than lexical
- Believing a label can target a sibling loop