carbon-lang/proposals/p0157_decision.md

Decision for: Design direction for sum types

Proposal accepted on 2021-02-02

Affirming:

• austern
• chandlerc
• geoffromer
• gribozavr
• josh11b
• zygoloid

Abstaining:

• noncombatant
• tituswinters

Open questions

None

Rationale

This proposal gives us solid ground on which to continue developing features that rely on sum types and pattern matching thereof. The approach taken seems plausible, and while there's a good chance that we will revise it significantly before we finish our first pass over the complete Carbon design (for example, by switching to pattern matching proxies or by supporting mutation of matched elements), we don't think it will anchor us too much on this one particular direction.

With regard to Carbon's goals:

• Performance: while the approach taken herein potentially has some performance cost for a common operation that is likely to appear in performance-critical code (requiring an indirect call and the generation of continuations for user-defined pattern matching), such cost should be practically removable by inlining. We'll need to take care to ensure this abstraction penalty is reliably removed in common cases, but this seems sufficiently feasible to be worth attempting.
• Evolution: software evolution is supported by allowing user-defined pattern matching to specify (by way of the presence/absence of operator default) whether the set of patterns is intended to be extended in the future.
• Ergonomics: custom pattern matching for user-defined types promotes language consistency and removes boilerplate

Note: At the decision meeting, it was stated that geoffromer will update the proposal to add a rationale to address austern's questions about the layered approach.