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.
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.
Practice what you learned
1. What problem do generics primarily solve in Dart?
2. Given `class Box<T> { T value; Box(this.value); }`, what type does Dart infer for `Box('hello')`?
3. What does the bound in `class SortedList<T extends Comparable<T>>` allow the class body to safely do?
4. How does Dart's generics implementation differ from Java's type erasure?
5. Why might a generic method mark a parameter as `covariant`?
Was this page helpful?
You May Also Like
Extension Methods
Learn how Dart's extension methods let you add new functionality to existing types — including types you don't own, like String or int — without subclassing or wrapping them.
Exception Handling in Dart
Learn how Dart represents and handles runtime errors using try/catch/finally, custom exception types, and the distinction between Exceptions and Errors.
Futures and async/await
Learn how Dart represents asynchronous computations with Future objects and how async/await syntax lets you write non-blocking code that reads like synchronous code.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics