overhauled proposal #65

zkat · 2018-03-24T20:13:38Z

After having some conversations with @tabatkins, @bterlson, @wycats, and others, I've put together a new proposal that I believe addresses a large swath of issues that were being discussed with the previous one.

It is largely the same proposal, with a few new features (such as Extractors), new semantics for matching, and slightly different syntax cause I like it better.

Everything is pretty thoroughly documented (considering this is a first draft), and I've made notes both about executive design decisions I made in the redesign, as well as some fields ripe for the bikeshedding that I believe are worth discussing.

To go with this proposal, I've also written an npm package that works as a regular JavaScript library -- it lacks some of the syntactic allowances, but is semantically identical to this proposal and the mapping between the sugared and desugared versions is consistent and straightforward, so folks would be able to play with it.

Also this is totally my first championed proposal since I became a delegate and I'm pretty damn excited 🙈 Thanks y'all for your support! I've wanted this feature myself for a loooong time, so I care a lot about trying to see it through to stage 4 💚

tomByrer · 2018-03-24T21:47:00Z

I also prefer the || syntax over :.

In general, as a middle-talented JavaScript dev, I find the new syntax & examples easier to pick up than the previous syntax. cheers

FireyFly · 2018-03-24T23:01:26Z

Re. @ and as, ES modules using as for binding imports under a new name makes that option seem a bit more consistent to me.

jvanbruegge

Just my two cents :)

jvanbruegge · 2018-03-25T00:03:13Z

README.md

+}
+
+match (2) {
+  x if (x === y) => x === y === 2 // guard comparison with variable


Will evaluate to false, because x === y is true, but true === 2 is not. Not sure if intended

It was originally unintentional but then I just left it because I figured it would get the point across. I may as well make it be actually valid, though.

jvanbruegge · 2018-03-25T00:05:53Z

README.md

+```js
+match (x) {
+  {x: 1, y} => ..., // the y property is required, and is locally bound to y
+  {} => ..., // matches any object


How would you match an empty object then? Shouldnt { ..._} (where _ is a normal variable name) match any object?

I believe the common case, by far, is for keys on objects to be optional, and forcing matches to be exhaustive would defeat the purpose of this kind of destructuring. I feel like special-casing only {} might be surprising. If you really wanna make sure it's an empty object, x if (!Object.keys(x).length) => ... would do that for you.

ljharb · 2018-03-25T08:07:42Z

README.md

+
+This document includes a [detailed description of the `match` API](#api), as
+well as conscious [design decisions](#design-decisions) that were made involving
+various details. Further down, you can also fine a section on


fine → find

ljharb · 2018-03-25T08:09:24Z

README.md

+
+    {type: 'toggle-todo', index} => ({
+      todos: state.todos.map((todo, idx) => idx === index
+        ? Object.assign({}, todo, {done: !todo.done})


These examples with Object.assign would probably be more representative if they used object spread

ljharb · 2018-03-25T08:16:29Z

README.md

+
+#### <a name="primitive-matcher"></a> > Primitives
+
+Primitive types will be matched with `===`. The following literals can be


This should use Object.is instead (SameValue), to properly handle NaN and -0

ljharb · 2018-03-25T08:17:12Z

README.md

+
+#### <a name="object-matcher"></a> > Objects
+
+Objects are destructured. Any variables mentioned in the match side MUST exist


Variables don’t exist in objects, properties do - either as own or inherited. Can this be reworded a bit?

ljharb · 2018-03-25T08:19:00Z

README.md

+  {x: {y: 1}} => ...,
+  {x, ...y} => ..., // binds all-other-properties to `y`.
+  {x, ...{y}} => ..., // SyntaxError
+  Foo {y} => ...,// matches an instance of `Foo` or, if


Is there a default Symbol.patternMatch on Object.prototype that’s instanceof, or is this the default behavior?

Separately, instanceof doesn’t work cross-realm, so I’m uncomfortable with relying on it as default behavior.

This is worth talking about -- right now, the check is simply whether or not a Symbol.patternMatch method is available to the object at all -- and the instanceof fallback only happens if that is true and Foo is typeof 'function'.

I agree that instanceof is a massive pain, specially around realms, but there's no generic "this type of thing" check that would facilitate what I consider a pretty important/common use case for extractors (basic class checks). So I kept it in there because the alternative is worse, imo.

My concern is that when such a mechanism exists - like @jasnell’s “builtins.is” proposal - that would be what we’d want as the default matching mechanism, not instanceof, and it might not be a change that’s possible to make later.

Do you have any ideas on how to have our cake and eat it too, with this? I think it'd be a really big loss for something like this if everyone is required to add their own method to every single class they make, just to do a type match, and I'm not sure what the status of builtins.is is -- if that ships first, that would solve this problem, though, I guess.

I've moved this into a bikeshed section so it can be addressed later.

ljharb · 2018-03-25T08:29:21Z

README.md

+the very very different `switch` semantics, and also has a very clear symmetry
+that allows `&&` to work just fine. It also fits with other pattern matching
+engines that allow alternatives like this actually do. I don't believe this is
+worth further bikeshedding.


I think the dissonance with the existing value selection operators, and the nullish coalescing operator, will necessitate further discussion here.

I'm not sure what dissonance you're referring to here (see above comment about them working off match-success, not actual values)

I think a dev will expect && anywhere to work like && everywhere.

I'm not so sure, since || doesn't make sense on the LHS of assignments already, but I'm willing to hear more options.

We could do what Erlang does and make it depend on ; or , or something ;)

(I would actually be very interested in finding ways to get more feedback from the community about this and other similar syntax bikesheds. I don't actually think there's an objective answer to this besides actual research -- and I've gotten a sense of positive responses about this construct so far from anyone who's noted it)

but for the sake of tossing stuff in the mix:

1 | 2 | 3 => ... and {x: 1}, {y: 2} => ... (for or and and, respectively) seem like they could be reasonable alternatives maybe?

The former collides with (the admittedly way less used) bitwise OR, but a comma separated list, or keywords like or and and seem like they’d work.

Rust uses | for pattern-match OR, and also has | as the bitwise operator (and || is a boolean OR). I'm even more comfortable with overloading bitwise here.

Alright, I've added a bikeshed section about this to the document so we can take this discussion out of a github issue thread: https://github.com/zkat/proposal-pattern-matching/blob/master/README.md#compound-matcher-syntax

ljharb · 2018-03-25T08:30:13Z

README.md

 }
 ```

-It is possible that array patterns could also match iterables, however it's not clear this design is desirable. First, it's not clear that users of pattern matching would expect array patterns to match any object with Symbol.iterable. Second, since pulling values out of an iterable is side-effecty, it introduces a lot of confusion around what the state of the iterable is in each match leg and it's not clear that side-effecty-by-default pattern matching is a good idea.
+Another argument in favor of the special case is so, instead of [making `match`
+automatically pun on `null` equality](null-punning), we can use `||` to do the equivalent of a


What is the definition of the term “pun” here?

Something like "use a separate, non-obvious construct for the sake of a convenient syntax".

For example: foo = foo || 1 for defaults, or x == null to just generally check for "things that are not there". They're both perfectly valid examples, but they rely on some cleverness for the sake of terseness. It's a term I've seen used elsewhere in language design discussions when it comes to such features. (see also, nil-punning in lisps)

Thanks, TIL

ljharb · 2018-03-25T08:33:29Z

README.md

 }
 ```

-## Identifier Patterns &amp; Symbol.matches
+Or, alternatively, using `|` if [`undefined` is


ljharb · 2018-03-25T08:43:05Z

README.md


-### Nested Matching
-Because match is an expression, you can match further in the consequent of a match leg. Consider:
+Another benefit of using `@` is that it could allow folks to use an extractor


It’s worth mentioning the conflict with decorators here.

ljharb · 2018-03-25T08:47:19Z

README.md

+##### Option D
+
+Similarly to Option C, the "magic constructor" could be stored in
+`Symbol.patternMatch` itself, and defining successful matches as anything that


Is there an option e, where we add an actual Maybe-like primitive?

We could add that, but it feels like a bit of a chicken-or-egg problem where a Maybe-like primitive is much less useful without a match-like construct. I'll definitely add this, because if that's on the table, I am ALL OVER THAT.

I’m not sure if it is or not, but I’ve been casually asking delegates about it for a few years on and off

might be worth pushing harder on it, though, since this would really benefit from that.

ljharb · 2018-03-25T09:30:55Z

README.md

-        throw new Error("Unknown vector type");
+function todoApp (state = initialState, action) {
+  const newState = match (action) {
+    {type: 'set-visibility-filter', filter: visFilter} => ({visFilter}),


How does this syntax work with matching Symbols and computed properties? Is it just a normal destructuring pattern?

I'm working off the assumption that {[Symbol.whatnot]: 'value'} would work just as well here, yes, since it works in regular destructuring.

I've added a note to the object-matcher section to make this explicit.

jsynowiec · 2018-03-25T11:49:36Z

README.md

+Champions: Brian Terlson (Microsoft, [@bterlson](https://twitter.com/bterlson)), Sebastian Markbåge (Facebook, [@sebmarkbage](https://twitter.com/sebmarkbage)), Kat Marchán (npm, [@maybekatz](https://twitter.com/maybekatz))
+
+This proposal adds a new feature to ECMAScript, called "Pattern Matching",
+through a new expression statement named `match`. Pattern matching is a feature


Maybe I've missed this, but what about using match as a variable name in a block? It's common to assign the result array returned by the match() method to a local variable named match.

const re = /([\w ]+)::(\d{1,2} \w+ \d{4}).*/i; const match = 'USA::14 February 2018 (internet)'.match(re);

Will it work or throw the SyntaxError: Cannot use the keyword 'match' as a lexical variable name. exception?

My understanding, specially considering the cover grammar comment in the syntax outline, is that match is not a reserved word but will actually still work when a lexical binding exists? Cc others who know this part better than me

leonardiwagner · 2018-03-26T02:36:17Z

I had some discussions about the initial design of this proposal, but I decreased my participation because I didn't feel it was being listened, even having many "likes" at some opinions (of course popularity doesn't mean being right).

Now, almost a year later, I'm glad seeing this impressive work, congratulations @zkat 👏 👏 👏, amazing job, and I feel good that somehow the discussions were productive (and finally the damn "else leg" was removed! haha 😂).

zkat force-pushed the master branch 5 times, most recently from 58ec0e0 to 961c234 Compare March 24, 2018 21:32

zkat force-pushed the master branch from 961c234 to d2be129 Compare March 24, 2018 22:33

zkat force-pushed the master branch 3 times, most recently from bc0cab0 to c5c370e Compare March 24, 2018 23:45

jvanbruegge reviewed Mar 25, 2018

View reviewed changes

zkat force-pushed the master branch 3 times, most recently from ec8466c to 7c25619 Compare March 25, 2018 07:02

zkat and others added 2 commits March 25, 2018 09:03

docs: replace with updated proposal

dba36d9

Minor fixes (#1)

da51515

zkat force-pushed the master branch from 3ba3caf to da51515 Compare March 25, 2018 08:03

docs: fixup

da6e28d

ljharb reviewed Mar 25, 2018

View reviewed changes

zkat force-pushed the master branch from 97a9ac2 to deaea1b Compare March 25, 2018 09:30

ljharb reviewed Mar 25, 2018

View reviewed changes

docs: address comments by @ljharb

e6f2704

zkat force-pushed the master branch from deaea1b to e6f2704 Compare March 25, 2018 09:36

zkat added 2 commits March 25, 2018 11:34

docs: add bikeshed about compounds

9b65361

docs: add bikeshed about instanceof and extractors

a766e20

zkat force-pushed the master branch from c59828b to a766e20 Compare March 25, 2018 10:35

docs: embiggen cynicism

7ac0e26

jsynowiec reviewed Mar 25, 2018

View reviewed changes

docs: misc details and fixes

9f327f6

xtuc mentioned this pull request Mar 26, 2018

tc39-proposal-pattern-matching babel/babel#6761

Closed

3 tasks


		#### <a name="primitive-matcher"></a> > Primitives

		Primitive types will be matched with `===`. The following literals can be


		#### <a name="object-matcher"></a> > Objects

		Objects are destructured. Any variables mentioned in the match side MUST exist

overhauled proposal #65

overhauled proposal #65

Conversation

zkat commented Mar 24, 2018 • edited Loading

tomByrer commented Mar 24, 2018 • edited Loading

FireyFly commented Mar 24, 2018

jvanbruegge left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

leonardiwagner commented Mar 26, 2018

zkat commented Mar 24, 2018 •

edited

Loading

tomByrer commented Mar 24, 2018 •

edited

Loading