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
●
As-Patterns:
gh/zkat/proposal-as-patterns
●
Collection
Literals:
gh/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
●
https://web.archive.org/web/20190716130840/https://github.com/tc39/proposal-patt
ern-matching
How
about
Stage
1?
😘
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