Challenge 1: Identify the Cliff — Possible Solution
====================================================================

type AllCombos<A extends string, B extends string, C extends string> = `${A}-${B}-${C}`;

// Given three unions A, B, C each with 15 members:
//
//   AllCombos<UnionA, UnionB, UnionC>
//
// Template literal types distribute over EVERY union they touch (the same
// distributive behavior Chapter 1 covered for conditional types) — so the
// result isn't 15 members, or even 15 + 15 + 15 = 45 members. It's the
// full cartesian product:
//
//   15 (A) × 15 (B) × 15 (C) = 3,375 total string literal members
//
// That single resulting union type — AllCombos<UnionA, UnionB, UnionC> —
// now has 3,375 distinct literal members that TypeScript must track as
// one type.

// WHY THIS IS A PERFORMANCE CONCERN IF REUSED ACROSS MANY FILES:
//
// 1. Every time this type is referenced (as a parameter type, a return
//    type, a generic constraint), the checker has to represent and
//    reason about all 3,375 members — not lazily, but as an actual
//    resolved union.
//
// 2. If this 3,375-member union then gets used as the input to ANOTHER
//    conditional type or template literal (e.g. checking "does this
//    combo string match a pattern"), that check may run once per member
//    of the union — multiplying the cost again, potentially into the
//    tens of thousands of individual checks for a single expression.
//
// 3. Editors run the type checker on every keystroke for inline
//    diagnostics — a type this large recomputed repeatedly while
//    someone is typing in a file that imports it is a common, concrete
//    cause of "why does my editor lag in this one file specifically."
//
// 4. Unlike a recursive type hitting TypeScript's depth limit (which at
//    least produces a clear compiler error), a large-but-finite
//    combinatorial union like this one compiles successfully — it just
//    makes every subsequent operation on it slower, which is much
//    harder to notice until it's already a real problem.

WHY THIS WORKS AS AN ANSWER
---------------------------
- The key insight is that template literal types (and conditional types)
  distribute over EVERY union type parameter simultaneously, not just one
  at a time — with three 15-member unions, the growth is multiplicative
  (15 × 15 × 15), not additive (15 + 15 + 15).
- Recognizing "this type takes N union type parameters, multiply their
  sizes together" is the fast mental check for whether a template
  literal type is heading toward a combinatorial explosion before ever
  running a profiler.