Object extractors syntax

[littledan]

I like paren-based extractors a lot, largely because they fit the general form of pattern matching and destructuring, where the LHS does something like the inverse of the RHS. Paren-based extractors are just undoing the function call!

In this context, I'm confused by the inclusion of object-based extractors. I'd hope to be able to write Foo{x,y} on the RHS if I can write it on the LHS. (I understand that this logic falls apart with defaults, but I think that's the only case.)

Why not do object extraction with syntax like let Foo({x, y}) = expr? This seems simpler and more regular.

[rbuckton]

In this context, I'm confused by the inclusion of object-based extractors. I'd hope to be able to write Foo{x,y} on the RHS if I can write it on the LHS. (I understand that this logic falls apart with defaults, but I think that's the only case.)

As mentioned in the explainer, I'm hoping to introduce compatible syntax on the RHS for ADT enums (and potentially general literal property construction). At this point in the TC39 process, I'd like to keep both syntax options on the table for exploration. Whether the object extractors syntax advances to stage 2 will depend on the committee's opinions on ADT enums and general property literal construction when those proposals come to (or come back to) committee in the future.

Why not do object extraction with syntax like let Foo({x, y}) = expr? This seems simpler and more regular.

While that's certainly feasible, that could break the intended consistency argument for ADT enums. That means that either extractors should support Message.Move{ x, y } on the left, or that enums would have to support Message.Move({ x, y }) on the right. Enums should be as lightweight as possible and should be record-like (i.e., immutable, === comparison, etc.), so enum construction like Message.Move({ x, y }) would not align well with those constraints since object literals cannot be placed inside of a Record.

[rbuckton]

I also believe that Object Extractors could supplant the with syntax in pattern matching:

match (input) {
  when ${Message.Write} with [text]: ...;
  when ${Message.Move} with { x, y }: ...;
}

// vs

match (input) {
  when Message.Write(text): ...;
  when Message.Move{ x, y }: ...;
}

In which case we would want to have both array and object patterns for custom matchers.

[littledan]

Good, I'm happy to consider this during Stage 1, and especially happy about this being in the context of parallelism with ADTs. Again, sorry for skimming too fast before filing the issue, and thanks for the explanation.

[littledan]

Thank you for addressing this issue! I'm really happy with the current state of the proposal.