Generics in Dart

Analogy categoryAnalogies

Why Generics? Type Safety Without Duplication

Without generics, a reusable container class would have to store elements as Object or dynamic, forcing callers to cast every value back to its real type and losing compile-time checking — a cast that fails only crashes at runtime. Dart's built-in collections are generic: List<int>, Map<String, User>, and Set<double> each enforce, at compile time, that only values of the declared type can go in and come out, catching type mistakes during development rather than in production. Generics let you write one class or function, like Box<T> or List<T>, that works correctly and safely for many concrete types.

🏏

Cricket analogy: Generics are like a bowling machine calibrated for a specific ball type — a cricket-only machine (List<CricketBall>) rejects a tennis ball fed in by mistake at setup time, instead of jamming mid-session the way an untyped machine accepting 'any object' would fail unpredictably during play.

Generic Classes and Methods

Declaring class Box<T> { T value; Box(this.value); } creates a class where T is a placeholder filled in at the point of use — Box<String>('hi') or Box<int>(42) — and the compiler enforces that .value really is that type everywhere it's used. Dart's type inference often lets you omit the explicit type argument: Box('hi') infers Box<String> from the constructor argument. The same mechanism applies to generic methods, such as T firstWhere<T>(List<T> items, bool Function(T) test), where the type parameter is scoped to that single method rather than an entire class.

🏏

Cricket analogy: A generic Box<T> is like a kit bag labeled for a specific format — Box<T20Gear> versus Box<TestMatchGear> — where the label (T) determines what's inside, and just seeing 'Kohli's Test kit bag' tells you it holds whites and a red-ball bat, not T20 gear.

dart

class Box<T extends Comparable<T>> {
  final List<T> _items = [];

  void add(T item) => _items.add(item);

  T get max => _items.reduce((a, b) => a.compareTo(b) > 0 ? a : b);
}

T firstOrDefault<T>(List<T> items, T defaultValue) {
  return items.isEmpty ? defaultValue : items.first;
}

void main() {
  final scores = Box<int>();
  scores.add(72);
  scores.add(95);
  scores.add(63);
  print('Highest score: ${scores.max}'); // Highest score: 95

  final names = <String>[];
  print(firstOrDefault(names, 'Unknown')); // Unknown
}

Bounded Type Parameters with extends

You can restrict what T is allowed to be with a bound, such as class SortedList<T extends Comparable<T>> { ... }, which lets the class body safely call .compareTo() on values of type T because the compiler knows every valid T supports that method. This is different from an unbounded <T>, where the compiler can only assume T is Object? and would reject calling anything beyond Object's methods like toString() or hashCode. Bounds are also common with <T extends num> for generic math utilities that need to call arithmetic-adjacent methods, or <T extends Widget> in Flutter APIs that only accept widget subtypes.

🏏

Cricket analogy: A bound like <T extends Comparable<T>> is like a fast-bowling academy that only accepts trainees who can already bowl above 130 km/h — the coaching program (class body) can safely design drills assuming that baseline skill, the way SortedList assumes T supports compareTo().

Unlike Java, where generic type information is erased at runtime, Dart's generics are reified — a List<int> genuinely remembers that it holds ints, so runtime checks like value is List<int> return accurate, meaningful results instead of always matching a raw erased type.

Generic Functions, Typedefs, and Variance

Top-level generic functions like T firstOrDefault<T>(List<T> items, T defaultValue) scope their type parameter to just that function call, and typedefs can also be generic — typedef Comparator<T> = int Function(T a, T b) — to name a reusable function shape. Dart's generics are also 'reified': unlike Java's type erasure, List<int> and List<String> remain genuinely distinguishable types at runtime, so list is List<int> gives a meaningful answer. Dart's generic collections are covariant by default (a List<Cat> can be assigned where List<Animal> is expected), which is convenient but means an unsafe write can still fail at runtime with a type error rather than compile time, which is why methods that intentionally accept a wider type mark their parameter covariant.

🏏

Cricket analogy: A generic typedef like Comparator<T> is like a standard scorecard template that different formats reuse — a T20 scorecard and a Test scorecard both follow the same template shape, just filled with different data, similar to how the same function signature works for any T.

Because Dart's generic collections are covariant by default, a List<Cat> catsList can be passed anywhere a List<Animal> is expected — but if that code then tries to insert a Dog through the widened reference, the mistake isn't caught until runtime with a type error, not at compile time.

Generics catch type mistakes at compile time instead of relying on unsafe runtime casts.
class Box<T> { ... } lets one class definition work correctly for any concrete type argument.
Type inference often fills in the type argument automatically from constructor or literal arguments.
Generic methods like T firstWhere<T>(...) scope their type parameter to a single call.
Bounded type parameters (<T extends num>) let the body safely call methods specific to that bound.
Dart generics are reified — runtime type checks on generic types are meaningful, unlike Java's erasure.
List<Cat> being assignable to List<Animal> (covariance) can defer some type errors to runtime.