Null Safety — ?, !, ??, ?., late, and Flow Analysis

By the end of this lesson you will know exactly what null is, why it was called "the billion-dollar mistake", how Dart 3's sound null safety catches null-related crashes at compile time instead of at 3am in production, and how to correctly use every null operator (?., ??, ??=, !, ...?, null-aware collection elements), late, required, and the analyzer's flow-based "promotion" of nullable types.

1. What null is, and the billion-dollar mistake

In 1965, Tony Hoare added null references to a language design because it was "so easy to implement". In 2009 he publicly apologised, calling it his "billion-dollar mistake" — because in most languages of the time (Java, C, C++, JavaScript, pre-2.12 Dart), any variable that looked like it held an object could secretly hold null instead, and the compiler never warned you. The crash only happens later, at runtime, the moment your code tries to actually use the missing value — for example calling .length on a String slot that is secretly empty.

The same locker in Dart: null is not 0, not '', not false; and the old-language crash, reproduced with dynamic (which switches the compile-time checks off):

2. Sound null safety: the type hierarchy

Dart 3 has sound null safety, always on (there is no "opt out" any more). Every type is non-nullable by default: String can NEVER hold null — the compiler guarantees it, and can rely on that guarantee when generating code (see the Expert-tier "soundness" question; exactly which checks get removed is a compiler implementation detail). To allow the empty state, you write a question mark after the type: String? means "a String, or null". This one keystroke turns off the guarantee for that specific variable and turns ON a new rule: the analyzer will not let you use it as a plain String until you've proven it isn't null.

Dart's type hierarchy, top to bottom: Object? is the absolute top — every single value in Dart, including null itself, is an Object?. Below it splits into Object (every real, non-null value) and Null (the type that has exactly one value: null itself). Every concrete class (String, int, your own classes) sits under Object. At the very bottom sits Never — a special type with NO values at all, used for expressions that can never successfully produce a result (like a function that always throws). Because Never has no values, it's compatible with every other type — see the Expert-tier "Never subtype" question.

The hierarchy as runnable checks (is Object is true for every non-null value; List<Never> fits where List<int> is expected):

Input size → what's feasible: the ? in a type is a compile-time label only — it adds no per-element memory or time, so String? over n = 10⁶ items costs the same as String.

3. Safe navigation: ?. and short-circuiting

a?.b means: if a is null, the whole expression evaluates to null immediately, without even attempting to read .b. If a is not null, it behaves exactly like a.b. This chains: a?.b?.c stops at the FIRST null it meets, and none of the getters after that point ever run — not even to check if they'd throw.

Its siblings: ?[] (null-aware index) and ?.. (null-aware cascade — the whole cascade is skipped when the receiver is null):

Input size → what's feasible: every null-aware operator is O(1) (one comparison against null); 10⁸ of them take about 1 s, so use them freely in loops over n ≤ 10⁷ items.

4. ?? and ??= — filling in defaults

a ?? b evaluates a; if a is not null, that's the result and b is never evaluated at all. If a IS null, the result is b. a ??= b is shorthand for "if a is currently null, set a = b; otherwise, change nothing" — it only ever assigns when the left side is empty.

Input size → what's feasible: ?? and ??= are one null test, O(1); the right side is only evaluated when needed, so an expensive fallback costs nothing on the non-null path (even for 10⁷ calls).

5. ! — the null assertion operator

expr! tells the analyzer "trust me, this is not null" and converts a nullable type to its non-nullable form AT COMPILE TIME. At run time Dart still performs one tiny null check there: if you were right it passes and the value flows on; but if the value actually IS null, Dart throws a TypeError immediately with the message "Null check operator used on a null value" — a hard crash, exactly the kind of crash sound null safety is designed to prevent everywhere else.

Input size → what's feasible: ! is one null test, O(1) — speed is never the issue; correctness is: one wrong promise out of 10⁶ calls still crashes the app.

6. Null-aware spreads and collection elements

Building lists from possibly-null pieces has its own null-aware syntax. ...?maybeList — the null-aware spread — inserts every element of maybeList into the surrounding list literal, or inserts NOTHING at all if maybeList is null (instead of crashing). Newer still (Dart 3.8+, verified against the installed SDK 3.11 for this lesson): a single null-aware element, ?expr, inside a list/set/map literal includes expr only if it's non-null, and is silently omitted if it's null — no need to build a whole spread for just one optional value.

Input size → what's feasible: a null-aware spread copies the list it spreads, O(k) for k elements; building a result from 10³ small pieces is instant, while spreading a 10⁶-element list inside a loop of 10⁶ iterations (10¹² copies) is not — use addAll there.

7. Flow analysis & type promotion

Dart's analyzer performs flow analysis: it walks your code path by path and tracks, at every single line, what it currently knows about each variable's nullability. The moment you write if (x != null) { ... }, inside that { ... } block the analyzer promotes x's static type from T? to T — you can use it exactly like a non-nullable value, with no ! needed. The same promotion happens with an is check (if (o is int) { ... o is usable as int here ... }), and with an early return pattern: if (x == null) return; // from here on, x is promoted to non-null for the rest of the function.

Every promotion source from the card below, as code — != null, early return, is, && / || short-circuit, and a non-null assignment:

Input size → what's feasible: promotion is a compile-time analysis, so it costs nothing at run time regardless of input size.

8. Why fields don't promote (and the fixes)

This is why if (obj.field != null) { obj.field.length } does not compile for a public instance field or getter — a subclass overriding field's getter could return null on the second read even though the first read didn't. The three fixes: (1) copy the field into a local variable first (final f = obj.field; if (f != null) f.length; — locals DO promote), (2) use a pattern: if (obj.field case final v?) { v.length; }, or (3) since Dart 3.2, a private final field (starting with _) with no custom getter override risk in the same library CAN be promoted directly, because the compiler can prove nothing outside the library can intercept it.

Input size → what's feasible: a null check plus a local copy is O(1), so every fix here is free at any input size (n = 10⁶ objects); pick by readability, not speed.

9. late and required

required applies to named parameters: void greet({required String name}) forces every caller to pass name — leaving it out is a COMPILE error, not a runtime surprise. late lets you declare a non-nullable field or variable without an initial value, on the promise that it will be set before it's first read. If you break that promise — read it before assigning — Dart throws a LateInitializationError at that exact read, with a message like "LateInitializationError: Field 'name' has not been initialized." Two cousins: late final may be assigned exactly ONCE (a second assignment throws the same kind of error), and late final String lazy = _load(); runs its initializer only on the FIRST read — a lazily computed value. Both are in the Dart panel below.

Input size → what's feasible: a late read adds one initialised-check (O(1)); a lazy late final x = expensive(); pays the cost once, on first read — good when only some of n = 10⁵ objects ever need x.

10. Null in collections: List<int?> vs List<int>?

These two types answer completely different questions, and mixing them up is a very common bug. List<int?>: the list reference is never null, .length always works, but list[i] can be null. List<int>?: you must null-check the LIST ITSELF before touching .length or indexing at all, but once past that check every element is a guaranteed int.

Input size → what's feasible: nonNulls / whereType are lazy O(n) filters: n = 10⁶ elements ≈ 10⁶ steps (fast); calling removeAt per null instead would shift elements, up to n²/2 = 5·10¹¹ moves.

Cleaning nulls out of a List<int?>: xs.whereType<int>() filters to only the elements that are an int (dropping null), returning an Iterable<int>. xs.nonNulls does the same specific job — drop every null — and reads more clearly for that exact purpose. (A related, very commonly used helper, firstWhereOrNull, safely returns the first matching element or null instead of throwing — it comes from the external package:collection, not core Dart, so it's mentioned here for awareness only and isn't exercised in this lesson's verification file.)

11. APIs that hand you null on purpose

Real Dart APIs use null as a deliberate, honest "nothing here" signal instead of throwing exceptions for expected, everyday absence: int.tryParse('abc') returns null (not a crash) when the text isn't a valid integer — contrast with int.parse('abc'), which throws a FormatException. A Map<K, V>'s operator [] has return type V?: map[missingKey] returns null rather than throwing, because "key not present" is a completely normal, expected outcome, not an error. stdin.readLineSync() (reading a line typed by a user) returns String?, because the input stream can legitimately end (e.g. Ctrl-D) with no more lines to give you.

Input size → what's feasible: tryParse reads the text once, O(L) for L characters (L ≤ 10⁶ is fine); Map[] is O(1) on average, so 10⁶ lookups ≈ 10⁶ steps.

Quiz

Interview questions

Cheat sheet