The Swift compiler is slow due to how types are inferred

Root causes of Swift compile slowness

• Main pain point: type checking of complex expressions, especially when literals, operator overloading, generics, and protocol conformances interact.
• The compiler must consider many combinations of overloads and literal types (e.g., + with many candidates, multiple ExpressibleBy…Literal adopters), causing combinatorial explosions even in small expressions.
• Some examples show invalid code taking ~40 seconds just to produce a type error, suggesting exponential behavior and possibly additional algorithmic/path/implementation issues.

Type system and inference debates

• Several comments stress that the core issue is not “type inference” per se, but Swift’s mix of:
  • Ad-hoc polymorphism via overloads.
  • Subtyping.
  • Very flexible literal typing.
• Comparisons are made to SAT/NP-complete/EXPTIME-hard problems; SAT solvers are mentioned as powerful but too unpredictable for compilers.
• Others argue this is partly self‑inflicted: aggressive operator overloading and many overloads for the same names create huge search spaces.
• Some suggest Swift’s understanding of “bidirectional type checking” is muddled; bidirectional systems can in principle improve performance if designed carefully.

Comparisons to other languages

• Haskell/OCaml/ML-style systems are cited as having powerful yet fast inference because they avoid subtyping and/or heavy ad‑hoc overloading.
• Demonstrations show Haskell handling similarly overloaded-looking code quickly, though pathological cases with gigantic inferred types still exist.
• Rust and Swift both forbid implicit numeric widening (e.g., Int * Double requires explicit conversion), but Rust is seen as getting more predictable inference and better error messages.
• Scala is mentioned as doing similar inference “a lot faster,” implying Swift’s performance is not theoretically inevitable.

Apple tooling, priorities, and ecosystem

• Some believe Apple’s developer tools org is under-resourced, causing a cycle: visible performance fixes around WWDC, then regressions as new features land.
• Explicit modules are cited as an example where promised compile-time wins turn into regressions for some projects.
• Others counter that Apple is investing in systemic fixes and that recent WWDCs show progress, so blanket “Apple doesn’t care” claims are seen as overstated.

Mitigations and alternative approaches

• Practical advice discussed:
  • Add explicit types or casts in “hot” expressions.
  • Break large expressions into smaller sub-expressions.
  • Limit or avoid clever operator overloading.
• Ideas for compiler behavior:
  • Early bail-out or warnings when it leaves a “fast path” and enters expensive search.
  • Incremental/incrementally cached type checking on ASTs.
  • Tools/CI that surface the worst offending expressions to encourage cleanup.
• Some suggest more radical design changes (stricter overloading rules, fewer implicit literal types) but acknowledge these would be source-breaking.