In Dart, how does a late final field differ from a plain final field, and what happens if code assigns it twice?

## Plain `final`: assigned once, proven statically A `final` variable can be assigned **only once**. For an instance field, Dart proves that at compile time by requiring the assignment during construction, in one of these places: - an **initializer** at the declaration: `final int retries = 3;` - an **initializing formal**: `Client(this.baseUrl);` - the **initializer list**: `Client(String url) : baseUrl = Uri.parse(url);` Anything else — assigning in the constructor body or in a method — is a compile error, because the field would be observable before it is set. ## `late final`: assigned once, checked at runtime `late final` keeps the **assign-once** rule but moves its enforcement to runtime, the same way `late` moves the initialisation check: ```dart class Session { late final String token; void start(String t) { token = t; // first write: fine } } ``` The runtime tracks two states for the field: 1. **Unassigned** — a read throws `LateInitializationError: Field 'token' has not been initialized.` 2. **Assigned** — a read returns the value; another write throws `LateInitializationError: Field 'token' has already been initialized.` This models values that are **set once, later, and immutable afterwards**: a controller created once the surrounding framework hands you what it needs, a connection opened by an explicit start step, a value computed after the constructor has finished because it needs `this`. For **local** `late final` variables, the analyzer goes further where it can: if flow analysis proves a second assignment will happen after the first, it reports `late_final_local_already_assigned` at compile time. ## The two forms of `late final` | Form | When set | Assignable from outside the initializer? | |---|---|---| | `late final T x;` | once, by any code with access | yes, exactly once | | `late final T x = expr;` | lazily on first read | no — compile error | The second form is a **lazy cached value**; it has no setter. The first form is a **write-once slot** and does have a setter. ## Trap: a public setter you did not intend Effective Dart's guideline **AVOID public `late final` fields without initializers** exists because of that setter. A normal `final` field has only a getter. A `late final` field without an initializer must be assignable after construction, so Dart generates a setter — and if the field is public, **any caller can perform that one assignment**, possibly before your own code does, which then fails with `has already been initialized`. The recommended alternatives: - don't use `late` — compute the value before construction, for example in a **factory constructor**; - initialise the `late` field at its declaration, which removes the setter; - keep the `late final` field **private** and expose a public getter. ## Other restrictions - A class with a generative **`const` constructor** cannot declare a `late final` field (`late_final_field_with_const_constructor`): a constant object must be fully known at compile time. - `late final` does not make the **object** immutable. `late final List<int> ids;` fixes which list the field refers to, not the list's contents. - Like any `late` variable, there is **no API to ask whether it has been set**. ## A familiar Flutter shape In Flutter code the most common `late final` field is a controller created in a `State` subclass once the state object is attached — `late final AnimationController _controller;` assigned exactly once and disposed later. The field is private, assigned in one place, and never reassigned, which is exactly the shape Effective Dart endorses.