This proposal has several parts:
-
A new syntax construct, the "matcher pattern", which is an elaboration on (similar to but distinct from) destructuring patterns.
Matcher patterns allow testing the structure of an object in various ways, and recursing those tests into parts of the structure to an unlimited depth (similar to destructuring).
Matcher syntax intentionally resembles destructuring syntax but goes well beyond the abilities and intention of simple destructuring.
-
A new binary boolean operator,
is
, which lets you test values against matchers. If the matcher establishes bindings, this also pulls those bindings out into the operator's scope. -
A new syntax construct, the
match()
expression, which lets you test a value against multiple patterns and resolve to a value based on which one passed.
Destructuring matchers:
-
array matchers:
[<matcher>, <matcher>]
exactly two items, matching the patterns[<matcher>, <matcher>, ...]
two items matching the patterns, more allowed[<matcher>, <matcher>, ...let <ident>]
two items matching the patterns, with remainder collected into a list bound to<ident>
. (Can useconst
orvar
as well; see "binding matchers". Only binding matchers allowed in that position; not anything else.)
-
object matchers:
{<ident>, <ident>}
has the ident keys (in its proto chain, not just own keys), and binds the value to that ident. Can have other keys. (aka{a}
is identical to{a: let a}
){<ident>: <matcher>, <ident>: <matcher>}
has the ident keys, with values matching the patterns. Can have other keys.{<ident>: <matcher>, ...let <ident2>}
has the ident key, with values matching the pattern. Remaining own keys collected into an object bound to<ident2>
.
-
binding matchers:
let <ident>
/const <ident>
/var <ident>
. Binds the matchable to the ident. (That is,[let a, let b]
doesn't test the items in the array, just exposes them asa
andb
bindings.)- (To bind a matchable and apply more matchers, use
and
to chain them:let a and [b, c]
.)
Value-testing matchers:
-
literal matchers:
1
,"foo"
,- etc. All the primitives, plus (untagged only?) template literals.
- also unary plus/minus
-0
and+0
test for the properly-signed zero,0
just uses===
equality.NaN
tests for NaN properly.
-
variable matchers
-
<plain-or-dotted-ident>
evaluates the name.If the name has a custom matcher (see below), it passes the matchable to the custom matcher function and matches if that succeeds. Otherwise, it just matches based on equality. (Uses
===
semantics, except that NaN is matched properly.) -
<plain-or-dotted-ident>(<matcher-list>)
evaluates the ident, grabs itsSymbol.matcher
property, then invokes it on the matchable. (Throws if it doesn't have aSymbol.matcher
property, or it's not a function.) If that succeeds, it further matches the result against the arglist, as if it was an array matcher.Option.Some(foo) examples goes here
-
-
regex matchers:
/foo/
matches if the regex matches. Named capture groups establishlet
bindings./foo/(<matcher-list>)
is identical to custom matcher - if the regex matches, then the match result (the regex match object) is further destructured by the matcher list.
Boolean matcher logic:
<matcher> and <matcher>
: Tests the matchable against both matchers (in order), succeeds only if both succeed. Accumulates bindings from both. If first fails, short-circuits.<matcher> or <matcher>
: Tests the matchable against both matchers (in order), succeeds if either succeeds. Accumulates bindings from both, but values only from the first successful matcher (other bindings becomeundefined
). If first succeeds, short-circuits.not <matcher>
: Tests the matchable against the matcher, succeeds only if the matcher fails. No bindings.- Matchers can be parenthesized, and must be if you're using multiple keywords; there is no precedence relationship between the keywords, so it's a syntax error to mix them at the same level.
-
New
match(){}
expression:match(<val-expr>) { when <matcher>: <result-expr>; default: <result-expr>; }
Find the first "arm" whose matcher passes, given the val. Evaluates to the corresponding result for that arm. The matcher can produce bindings that are visible within the matcher and within the result; they don't escape the arm they're established in. (Are
var
matchers allowed or disallowed?)default
arm always matches. If no arm matches, throws. -
New
is
operator<val-expr> is <matcher>
Evaluates to true/false if val passes the matcher or not. If the matcher has binding patterns, within the matcher they behave as normal; see below for behavior outside of the matcher.
Doing it manually with match() would be:
let passes = match(<val-expr>) { when <matcher>: true; default: false; }
-
When
is
is used and the matcher establishes bindings:-
In
if()
, the bindings are lifted to a scope immediately outside theif()
block, encompassing the followingelse
as well. (Likely, we define an analogous scope to whatfor(of)
uses.) Lexical bindings are TDZ if the matcher doesn't match.var
bindings simply don't set a value if the matcher doesn't match.(Bindings will often not be useful in the
else
, but will be in cases likeif(!(x is <matcher>)){...}else{...}
, where the matcher successfully matches but theif
fails.) -
In
while()
anddo{}while()
, same behavior. (Indo{}while()
, lexical bindings are TDZ on the first iteration.) -
In
for-of
, the bindings exist in the current outerfor
scope, same as any other bindings established in thefor
head.(TODO: write an example of for-of usage; I'm not clear how it's supposed to work.)
-
(We've lost matchers in plain let
/etc statements, which I guess also means we lose matchers in function arglists. Unfortunate.)
Sure, I'm being a little loose here because we didn't need precision to communicate with each other. I agree with your naming suggestinos.
Ah, no, I'd just forgotten to update that to the new binding syntax.
{a}
should be equivalent to{a: let a}
. Same with the...
bit.Sure. I would like it if
[]
access was allowed - I hate introducing these sort of restrictions to the language unnecessarily. But no parens, as obviously it would clash with the parens of the invocation.No, it's to let named groups work at all, if we say that the match result is the regexp match object. If that is indeed the case, then you only have access to the integer groups via the arglist, as the regexp result is an array-like.
We could instead say that the result of a regexp pattern is an iterator containing just the regexp match object; that way the code you wrote would work, and you could get at the positional groups like
/(f..)(b.r)/([_, f, b])
. Hm, that might indeed be better.I don't see the connection.
RegExp.$1
is mutable global state. This is local lexical bindings.Nah
{middle}
is fine there, as noted above. (We could still allow let/const/var there, if we feel a need to make it the type of binding specificiable in the shorthand, but as you can do so by just repeating the name, andlet
is the most obvious default choice, I think it's fine as-is.)I'd removed it from the patterns, as I got pushback on it last time, but I'm happy to add it back in. I agree that it's good as a pattern rather than as an addition to the
when
clause, as it makes it usable inis
and generally keeps the test close to where the binding is established.I assume we want wide-open expressions grammar on the RHS of the colon, which precludes using
,
as that's a valid expression operator.Ah kk, thanks.
Auuuggghhhh I hate that so much >_<
Yeah it's that array pattern ambiguity that bit me last time. I'm fine with putting it to the side for now and thinking about it for a level 2. Proper integration with function parameters might end up wanting to be fancier, anyway.
Yeah, I presume
catch when <pattern> {...}
is what we'll end up with, it reads well and is exactly analogous to thematch()
arms. If it's objectionable to have consecutivecatch
blocks, then thecatch match { when ...; }
syntax seems like the obvious second choice.Currently the answer is "you can't" - you have to use a
let _
binding pattern and just have your linter know to ignore that variable.The
_
custom matcher is cute, tho. ^_^