search

tc39 / proposal-pattern-matching

Pattern matching syntax for ECMAScript
https://tc39.es/proposal-pattern-matching/
MIT License
5.51k stars 89 forks source link

Update proposal to match new group consensus #293

Closed tabatkins closed 8 months ago

tabatkins commented 1 year ago

WORK IN PROGRESS, DO NOT MERGE

Rewriting the proposal to be in line with https://gist.github.com/tabatkins/51f35f88d7eea61d9ecbe3e82da817a5, as agreed by the champion group.

Currently I've only got the matchers rewritten as a first pass; have not yet done the match(){} expression or the is operator.

Closes #314. Closes #313. Closes #303. Closes #301. Closes #299. Closes #297. Closes #283. Closes #282. Closes #281. Closes #264. Closes #255. Closes #253.

Jack-Works commented 1 year ago

Do we have these patterns (relation patterns) in this PR from @rbuckton?

when (x > 20 and < 40) ...
tabatkins commented 1 year ago

Do we have these patterns (relation patterns)

No, they don't have champion consensus yet.

Jack-Works commented 1 year ago

Hi @tabatkins did you forget the if matcher?

when pattern: ...
if (expression): ...
default: ...
tabatkins commented 1 year ago

Phew, ok, I think the proposal might actually be done now, at least as a first draft.

Jack-Works commented 1 year ago

Userland classes auto-define a default custom matcher if a Symbol.customMatcher static method is not present in the class definition. This is effectively:

class MyClass {
    #__unique_name_here__;
    static [Symbol.customMatcher](subject) {
        return #__unique_name_here__ in subject;
    }
}

I don't agree with this part, I hope the readme can point out this has not been a concensus

My reason:

I'll refer to the discussion of class.hasInstance proposal. https://github.com/tc39/notes/blob/e42829d6f030722e3b108bd90cfdcc37878f7f98/meetings/2021-01/jan-27.md

JHX: If the class does not have class.hasInstance, it does not need to have class brand and it does not need to add the brand to the instance of this class. So for example if it uses a real instanceof check, then every class would need the brand and every objects need to have the brand lists. So it will have a very huge memory cost. So that is why it should be opt-in.

That proposal is opt-in, but this semantics is opt-out. I don't think we should have this, I also don't think engine like this.

ljharb commented 1 year ago

JS code is often not "hackable" by default, including the oldest thing, "variables in a closure", as well as all the builtins having internal slots. The entire point of private fields was to prevent that kind of hackability, and that is the direction we've been moving the language farther in.

Performance cost is up to engine implementors to consider.

Jack-Works commented 1 year ago

The new spec (https://github.com/tc39/proposal-pattern-matching/pull/295) is ready for review, I hope you can pick some ideas from it and update the README because more details are considered when writing the spec than just considering the normal cases. thanks!