# Pattern Matching In JavaScript TC39 May 2018 - Kat Marchan - npm, Inc. --- ## Matching the What-what? - Common feature in modern languages (Rust, Elixir, F#, C#) - Destructuring + Conditionals - Sort of an advanced switch (“super switch”) - Common, central logic branching in languages that support it --- ## Ok but what about JS? --- ## Ok but what else? --- ## Three separate proposals: - Core Proposal: [gh/tc39/proposal-pattern-matching](https://github.com/tc39/proposal-pattern-matching) - As-Patterns: [gh/zkat/proposal-as-patterns](https://github.com/zkat/proposal-as-patterns) - Collection Literals: [gh/zkat/proposal-collection-literals](https://web.archive.org/web/20190716130840/https://github.com/zkat/proposal-collection-literals) --- ## Core Proposal: The Big Picture - New Conditional Statement - Semantics closely based on Destructuring Assignment/Binding - Minimal Viable Proposal keeps new feature introduction to a minimum - Avoids overlap with other existing proposals but keeps compatibility in mind - Additional behavior forked into Collection Literal and As-Pattern proposals --- ## Core Proposal: Overview --- ## Core Proposal: Scope Semantics --- ## Core Proposal: Design Decisions - No Fallthrough (neither explicit or implicit) - Variables are irrefutable patterns: no var-val-based matching - Object.is() for non-collection comparison - Only one match param (no `match (x, y) {...}`) --- ## Core Proposal: Performance Considerations - Current semantics should be highly compilable (separation between static + runtime) - PIC-cacheable branches by internal Map (the v8/Self thing, not the userland Map) - Existing optimizations for destructuring should be reusable --- ## Core Proposal: Pathological Cases - Should there be a special case for some of these? What’s the full set? Infinity is already special-cased in some situations, iiuc. --- ## Core Proposal: Syntax Questions - Currently specced to use NLTH. This is not desired. - Current alternatives are lacking, but existing - Best + most effective solution is `s/match/case/g` - Also `super switch (...) {}` - Drawback to existing reserved words: superficial confusion --- ## Core Proposal: Other Pending Questions - Special-case Infinity/NaN/etc? - Some WIP on specifics of behavior w/ Iterators and []-patterns - Hoping for other two proposals for particularly exciting stuff - Consider `when new Foo(a, b, c) ->` patterns? --- ## Core Proposal: Stage 0 ### How about Stage 1? 😘 https://github.com/tc39/proposal-pattern-matching --- ## Side Proposal: As-Patterns - Explicit syntax for binding **_original values_** when destructuring - Based on `import` syntax’s `as` clauses --- ## Side-Proposal: As-Patterns Useful with both arrays and objects, in any DestructuringBinding: --- ## Side-Proposal: As-Patterns Big Motivator: Integration with `match` statement --- ## Side-Proposal: Collection Literals - Bidirectional Literal Syntax (destructuring AND construction) - Easy construction of collections using familiar syntax - `new Map([[]][][[[][][][][]]][[[][]]][[]]]]]])` is hell - Nice sugar over programmatic protocols --- ## Side-Proposal: Collection Literals Construction: --- ## Side-Proposal: Collection Literals Destructuring: --- ## Side-Proposal: Collection Literals Pattern Matching: --- ## Side-Proposal: Collection Literals - Exceptionally useful for Pattern Matching - Having all 3 makes the feature more straightforward - Great for integrating new standard and custom data structures - `Constructor.from()` + iterator for creation - `instance[Symbol.valueOf]()` returns iterator for matching