skip to content

What is the `field` keyword, and inside which scope is it available?

level: middleimportance: must knowfreq 75%

answer

  1. field = the backing field's storage slot
  2. only in scope inside that property's get/set
  3. use field to avoid setter recursion
  4. no field generated if accessors never use it
  5. this.x goes through accessor; field bypasses it

basics

~10 s

field refers to the property's hidden storage slot. You can only use it inside that property's getter or setter. It lets you read or write the stored value without calling the accessor again.

solid answer

~40 s

`field` is a special identifier available only inside a property's accessors (its getter and setter). It refers to the **backing field** — the synthesized storage slot for the property. You use it to avoid infinite recursion: writing `value` instead of `field` in a setter would call the setter again. The compiler generates the backing field **only if** `field` is used in at least one accessor (or the property relies on a default accessor that stores a value). Typical use is a custom setter that validates or normalizes before storing: `set(value) { field = value.trim() }`. `field` is in scope only within the accessor block of that exact property; it is not accessible elsewhere in the class.

code

kotlin · 8 lines
kotlin
class Account {
    var balance: Long = 0
        get() = field            // default-style getter
        set(value) {
            require(value >= 0) { "no overdraft" }
            field = value         // store directly, no recursion
        }
}

go deeper

for a junior

Recognizes field is used inside custom getters/setters to access stored value.

for a middle

Explains the recursion trap and that field is accessor-scoped, plus the validating-setter pattern.

for a senior

Knows the precise rule for when a backing field is or isn't generated and the difference between field and going through the accessor.

for a principal

Reasons about encapsulation/invariants enforced in setters and the cost/benefit of computed vs stored properties in a public API.

## The backing field When a property needs to *store* a value, the compiler creates a hidden field for it. Inside the property's own accessors you reference that storage through the keyword **`field`**. This is the only way to read/write the stored value directly. ## Why `field` exists Inside a getter or setter you cannot use the property name to touch storage, because the property name *is* the accessor call — that would recurse forever: ```kotlin var name: String = "" set(value) { name = value // BUG: calls set(value) again -> StackOverflowError } ``` The correct version uses `field`: ```kotlin var name: String = "" set(value) { field = value.trim() // writes the backing field directly } ``` ## Scope `field` is visible **only inside the accessor body** of the property it belongs to. You cannot write `field` in a method, constructor, or another property's accessor. ## When a backing field is generated The compiler generates a backing field **only if**: - the property uses `field` in at least one accessor, **or** - it uses a **default accessor** that reads/writes stored state (e.g., a plain `var x = 0`). If both accessors are fully custom and never touch `field`, **no** backing field is generated — the property is computed: ```kotlin val isEmpty: Boolean get() = size == 0 // no field; computed from other state ``` ## Common pattern: validating setter ```kotlin var score: Int = 0 set(value) { require(value >= 0) { "score must be >= 0" } field = value } ``` The getter is the default (returns `field`); the setter validates then stores. ## Related: `field` vs `this.x` `this.x = ...` goes **through the setter** (and can recurse). `field = ...` bypasses the accessor and hits storage directly.

  • What happens if you write `name = value` instead of `field = value` in a setter?
    It re-invokes the setter, causing infinite recursion and a StackOverflowError at runtime.
  • Can you reference `field` from a regular member function?
    No. `field` is only in scope inside the accessor block of its own property.

saying these in an interview costs you the question

  • Saying `field` is available everywhere in the class
  • Confusing `field` with `this`
  • Claiming a backing field is always generated
  • Using the property name to store state inside its own setter

context

resolving links…