2024-04-01 [03:05:15.0921] hey folks, are we meeting today? [07:54:23.0997] I’m not sure we need to - separately I’m not feeling well, so I’ll be late if we are. [08:25:03.0883] I am also not feeling well, so will not be in attendance unless there is a need. 2024-04-04 [08:04:33.0960] I'm confused by this example in the README.md, I don't think the 2nd parameter matches the proposed spec text: ```js RegExp.prototype[Symbol.customMatcher] = function(subject, {matchType}) { const result = this.exec(subject); if(matchType == "boolean") return result; if(matchType == "extractor") return [result, ...result.slice(1)]; } ``` Isn't the 2nd argument just a string, and aren't the possible values `"boolean"` and `"list"`? [08:12:02.0289] Also, I'm not sure I agree with the result for a RegExp custom matcher as suggested here: https://github.com/tc39/proposal-pattern-matching?tab=readme-ov-file#regex-extractor-patterns To match against a RegExp, you may want to match against either named capture groups, positional capture groups, or the whole match. I think the matcher could just be: ```js RegExp.prototype[Symbol.customMatcher] = function(subject, hint) { const result = this.exec(subject); if (hint === "boolean") return !!result; if (hint === "list") return result && [result]; } ``` And the pattern would look like: ``` when /(?\d+) \+ (?\d+)/({groups:{let left, let right}}): ...; when /(\d+) \* (\d+)/([void, let left, let right]): ...; when /\d+/([let digits]): ...; ``` [08:15:22.0406] The extra outputs from `...result.slice(1)` seem like unnecessary overhead for the sake of convenience as I doubt engines will optimize them away if unused. [13:47:00.0985] I was kinda wanting to be able to do the second and third cases as just `(void, let left, let right)` and `(let digits)` rather than requiring an array pattern as well, but I suppose that's not a big deal, yeah. [14:03:38.0770] `(let digits)` doesn't work if you want to access groups. (at least, not without the abandoned `Foo{ }` syntax). [14:08:13.0032] I'm in the middle of writing some code using C#'s pattern matching, and I may want to bring https://github.com/rbuckton/proposal-shorthand-improvements back at some point. C# has an object initialization syntax that lets you write code like this: ```cs var a = new Foo() { Bar = 1, Baz.Quxx = 2, } ``` which amounts to ```cs var a = new Foo(); a.Bar = 1; a.Baz.Quxx = 2; ``` and `{ Baz.Quxx = 2 }` is essentially the same as `{ Baz = { Quxx = 2 } }`. [14:09:44.0076] And unnamed types can be `new { Bar, Baz.Quxx }` which is essentially `new { Bar = Bar, Quxx = Baz.Quxx }`. [14:10:31.0242] Apparently they have a similar shorthand syntax for pattern matching, `x is { Bar: 1, Baz.Quxx: 2 }`, which is the same as `x is { Bar: 1, Baz: { Quxx: 2 } }`. [14:11:47.0372] Definitely not an MVP feature, but the deep property pattern seems potentially valuable and we're already parsing dotted names for extractors. [14:12:36.0879] * I'm in the middle of writing some code using C#'s pattern matching and ran into an interesting mechanism. C# has an object initialization syntax that lets you write code like this: ```cs var a = new Foo() { Bar = 1, Baz.Quxx = 2, } ``` which amounts to ```cs var a = new Foo(); a.Bar = 1; a.Baz.Quxx = 2; ``` and `{ Baz.Quxx = 2 }` is essentially the same as `{ Baz = { Quxx = 2 } }`. [14:44:54.0886] yeah, not an mvp, but that's definitely something we might want to do in the future 2024-04-05 [08:15:00.0655] > The pattern-matching champion group designed this proposal with a layering approach. It does not mean the proposal is an MVP. The champion group wishes to ship the proposal as a whole when possible, but we can drop some features if there is strong pushback from the committee. > This approach allows the champion group to consider how all features combine and also how the proposal should behave if any of the features are missing. I hope this is the consensus, am I wrong? MVP may leads to another class design in my pov 2024-04-08 [15:41:38.0996] In the proposal `{}` explicitly matches `Object`, but destructuring does not. By restricting `{}` to `Object` you can't have patterns like ```js match (value) { } [15:41:49.0408] * In the proposal `{}` explicitly matches `Object`, but destructuring does not. By restricting `{}` to `Object` you can't have patterns like ```js match (value) { when String & { length: 3 }: ...; } ``` [15:42:23.0066] IMO, the only things that shouldn't match `{}` are `null` and `undefined`. [15:43:07.0395] +1, TS got this one right [15:43:27.0054] https://tc39.es/proposal-pattern-matching/#sec-object-pattern-matches, every single Step 1. [15:44:05.0483] yeah that seems like an oversight. [15:44:35.0918] `{ length: 0 }` needs to match an empty string, eg [15:44:47.0549] * `{ length: 0 }` needs to match an empty string, for example [15:46:04.0572] It does mean that restricting things to a spec Object is a bit more complicated, though hopefully that can be handled by `when Object:` even for functions [15:46:35.0173] `when Object` indeed must match anything for which `Object(x) === x` [16:06:43.0074] Probably still a little too early for a thorough review of the spec, but I noticed that https://tc39.es/proposal-pattern-matching/#sec-match-expression-clauses-runtime-semantics-evaluation only cares about ECMAScript language values rather than completion values, which doesn't work as it prevents ThrowCompletion from bubbling out of match (or `return`/`break`/`continue` in the event `do` expressions are supported). 2024-04-09 [19:57:09.0263] > <@ljharb:matrix.org> `{ length: 0 }` needs to match an empty string, for example We don't do type coerce, but do we need to do primitive boxing? [19:57:35.0693] i mean, we could decide not to. but that would be a radical departure from the rest of the language. [19:57:58.0090] if you can do `x.length` on it, and you can do `const { length } = x` on it, you should be able to `{ length }` pattern match on it [19:58:10.0410] so i think "consistency with destructuring" forces us to do boxing, full stop [20:00:10.0273] let's decide it next group meeting [20:00:38.0329] sure, that's fine, but i'm not clear on what possible argument could justify "different from destructuring" [20:01:00.0825] > <@rbuckton:matrix.org> Probably still a little too early for a thorough review of the spec, but I noticed that https://tc39.es/proposal-pattern-matching/#sec-match-expression-clauses-runtime-semantics-evaluation only cares about ECMAScript language values rather than completion values, which doesn't work as it prevents ThrowCompletion from bubbling out of match (or `return`/`break`/`continue` in the event `do` expressions are supported). returns either a normal completion containing either an ECMAScript language value or not-matched, or an abrupt completion [20:01:11.0351] also MM just posted an issue moments ago, and i'm not sure i understand it, but it seems like it's in direct conflict with the "bindings by default" change we made in response to yulia's feedback [20:01:12.0910] Why do you say so? It contains Abrupt Completion [20:54:39.0006] > <@jackworks:matrix.org> returns either a normal completion containing either an ECMAScript language value or not-matched, or an abrupt completion Not the return. Step 2 of the 2nd and 3rd productions: > 1. Let result be ? MatchExpressionClausesEvaluation of MatchExpressionClauses with arguments subject and cacheGroup. > 2. If result is an ECMAScript language value, return result. > 3. Return ? MatchExpressionClauseEvaluation of MatchExpressionClause with arguments subject and cacheGroup. _result_ will never be an ECMAScript language value. We need to check for a normal completion whose value is `not-matched`. [20:55:14.0495] Wait, I'm an idiot. That's handled by 1. [20:55:44.0179] That's what I get for reading spec text on a 5hr car trip. [20:57:36.0048] The use of ReturnIfAbrupt (?) sort of obfuscates the intention, IMO. It was easy to overlook the fact that what we care about is `not-matched`. [20:58:16.0503] Either by explicitly looking for `not-matched`, or by adding an "Assert: _result_ is `not-matched`" [21:08:49.0321] I'll do that next time 2024-04-10 [18:33:13.0268] It occurred to me while responding to https://github.com/tc39/proposal-pattern-matching/issues/322 that we could potentially simplify a pattern like `Number and let x` as `Number x`, i.e., treat `Pattern identifer` as `Pattern and let identifier`. You still need `let` for cases where you don't need some other pattern, but it would cut down on repetition in other places: ```js match (command) { [("up" | "down" | "left" | "right") and let direction, Number and let steps]: handleMove(direction, steps); ["jump", Number and let howHigh]: jump(howHigh); } ``` Could be simplified to ```js match (command) { [("up" | "down" | "left" | "right") direction, Number steps]: handleMove(direction, steps); ["jump", Number howHigh]: jump(howHigh); } ``` Though if we did want to support that, I'd almost want it to be a follow on so the community would have time to understand how `let`/`const` patterns work first. [18:34:32.0950] I should note that this is actually somewhat similar to C# variable patterns as well, since C# variable patterns are actually `type identifier`, where `var` is a keyword that means "infer the type". [18:37:45.0979] i.e., `x is string y` and `x is string and var y` are equivalent in C# 8.0 [18:46:53.0225] * It occurred to me while responding to https://github.com/tc39/proposal-pattern-matching/issues/322 that we could potentially simplify a pattern like `Number and let x` as `Number x`, i.e., treat `Pattern identifer` as `Pattern and let identifier`. You still need `let` for cases where you don't need some other pattern, but it would cut down on repetition in other places: ```js match (command) { [("up" or "down" or "left" or "right") and let direction, Number and let steps]: handleMove(direction, steps); ["jump", Number and let howHigh]: jump(howHigh); } ``` Could be simplified to ```js match (command) { [("up" or "down" or "left" or "right") direction, Number steps]: handleMove(direction, steps); ["jump", Number howHigh]: jump(howHigh); } ``` Though if we did want to support that, I'd almost want it to be a follow on so the community would have time to understand how `let`/`const` patterns work first. [22:30:24.0352] with the recent github discussions i'm wondering if we even want to present pattern matching this meeting :-/ certainly we won't be asking for stage 2 [04:24:18.0943] Please don't ask for Stage 2, we share the concerns about complexity and at the very least need more time to evaluate the proposal as it stands. [04:25:11.0247] I'll open an issue with some of my questions / concerns. We also have a team work week next week, and I'm hoping to do a deep dive on this proposal and get more feedback then. [05:17:05.0002] would be interested in knowing whether the issue I had written up resonates for your team [06:40:19.0073] also i don’t have any slides from TabAtkins yet. anyone object to me removing pattern matching from the agenda? [06:49:10.0856] In general I think it would be better to remove all of the syntax that is contentious from the proposal spec text, there's just way too much in there we don't have consensus on. Put the optional or contentious things in its own document to make the spec less intimidating. [06:56:30.0289] For example, `?`/`has`/`hasOwn` look interesting as a follow-on, but maybe not MVP since they each can be solved in different ways. Maybe even RegExp patterns, considering the potential parser ambiguities, and can still be handled via an extractor by pulling the RegExp out of the pattern. Even relational patterns, despite my preference for inclusion, are not necessarily an MVP -- C# did not include them in their initial support for pattern matching either. Put all of these and anything else we lack consensus on into a separate document we can refer to regarding future capabilities, so that we can be sure we're considering them in the design space.' [06:56:31.0946] * For example, `?`/`has`/`hasOwn` look interesting as a follow-on, but maybe not MVP since they each can be solved in different ways. Maybe even RegExp patterns, considering the potential parser ambiguities, and can still be handled via an extractor by pulling the RegExp out of the pattern. Even relational patterns, despite my preference for inclusion, are not necessarily an MVP -- C# did not include them in their initial support for pattern matching either. Put all of these and anything else we lack consensus on into a separate document we can refer to regarding future capabilities, so that we can be sure we're considering them in the design space. [06:59:23.0286] I don't think `match(v) {}` and `is` are themselves a tough sell, despite cover grammar issues to work out. The pattern syntax is what's expansive and needs to be paired down, so long as we ensure we continue to maintain the pattern matching invariants we've established. [07:02:21.0776] > <@ljharb:matrix.org> also i don’t have any slides from TabAtkins yet. anyone object to me removing pattern matching from the agenda? do we need to still share updates, but not asking for stage 2 [07:03:18.0502] i don’t know if there’s even a point in sharing updates yet - it’ll just invite debate on things we’re likely to still change [07:13:28.0086] i kind of think it would be best to skip the update, we're seeing good conversations on github already [07:35:05.0889] ok, removing it [08:12:08.0397] 🫠 [08:12:31.0754] maybe in finland [08:12:37.0985] * maybe we can present at the finland meeting [08:15:04.0907] looks like the only way for proposals to get outside reviews is to put it on the agenda asking for an advance [08:15:15.0479] this is unhealthy [08:16:39.0171] i mean in this case we kind of discouraged outside reviews until that time [10:22:44.0423] Hi all, as an introduction - I work at Meta, and there is interest in experimenting with adding support for pattern matching (as part of Flow) internally, and potentially exposing it to our ~10k JS engineers for feedback. So, I'm excited and interested in the design and advancement of this (and related) proposals! [10:43:11.0298] This interest extends beyond pattern matching, to also ADT enums as well (which seem to be discussed above as well), as an extension to Flow Enums [10:51:55.0001] > <@gkz:matrix.org> This interest extends beyond pattern matching, to also ADT enums as well (which seem to be discussed above as well), as an extension to Flow Enums Another good place to join to discuss `enum` would be https://matrix.to/#/#temp-enum-interests-group:matrix.org [13:20:06.0761] Pattern matching humor: `that is { question: 0x2b or not 0x2b }` [14:29:11.0846] Sorry everyone, I've *very suddenly* gotten extremely swamped this past week. I was gonna finally have time this afternoon to do the slides, since we were presenting on Thursday, but I guess I don't need to now 2024-04-11 [19:03:18.0661] I'll be honest, I really do not like `~=`. It's not semantically meaningful, it looks like a compound assignment, and `~` is extremely inconvenient for non-us-english keyboard layouts. It only pushes the problem down the road. `is` might require more work for a cover grammar, but the bigger problem, IMO, is regular expression literals. [21:56:15.0583] i agree; i don't like `~=` and i don't think token soup is going to be an improvement [21:59:19.0217] i think having new binary english keywords is important enough that we should halt or alter any proposals that threaten that path [21:59:23.0137] * i think having new binary english keywords (in general) is important enough that we should halt or alter any proposals that threaten that path [01:28:13.0424] To me `~=` reads first as "not equal" rather than "approximately equal", given how `~` is used as a bitwise not operator in many languages, including C, Java, and Python. [01:29:30.0388] Also, hi! I recently got rather interested in extractors, and thought that therefore this might be a good place to hang out. [01:44:24.0440] I think in Perl and Ruby it's `=~` ? [02:39:22.0320] In perl `=~` is doing regexp matching; in Ruby it seems to be doing both that _and_ negation, _and_ it's user-customizable. [03:07:52.0184] I'll think a~=b is a=a~b (is it even a thing? but looks like bit operator to me) [06:28:17.0098] rkirsling: I read the issue you created and it aligns with my concerns about this proposal. I think that a python style `match` *statement* is a sufficiently powerful construct, and I'm not seeing an argument as to why we need something more powerful in the language. I'd like to see the champions present on why that design alternative was considered and found not suitable for JavaScript. [06:28:39.0352] I also think that `is` should be saved for a follow on proposal. I'm not convinced we need it, and it already seems problematic. [06:52:58.0822] `is` is profoundly useful. It covers a large number of use cases, including those offered by `if..let` and `while..let` in some languages, `not in` and `not instanceof`, and even `let..in`. It's far too useful, IMO. [06:53:29.0686] `=~` is not viable either as `a =~ b` is already legal JS. [06:56:17.0000] For me, the fact that `is` is that powerful is an argument for it to be a follow-on proposal, not for it to be part of this proposal. [07:12:40.0573] dminor: we made `is` after yulia and spidermonkey's feedback of making simpler composable pieces that build up to pattern matching [07:20:50.0887] That's not really an argument for including it in this proposal, rather than a follow-on. [07:21:29.0161] As I understand it, that was an argument for it to be in the proposal. Having it as a follow-on is counterproductive [07:21:35.0946] it's an argument for having `is` go first, and `match` as the follow-on [07:21:54.0915] the champion group didn't want to ship it piecemeal but that's my understanding of what spidermonkey wanted [07:22:27.0113] if you check the spec (not the readme) you'll find I wrote the spec in a way that most of the "complexities" can be broken down to simper (but unnecessary annoying long) building block [07:23:33.0487] e.g. pattern "{x?: y}" can be "{} or {x:y}" if you don't want "?:" [07:23:48.0185] I documented all these situations [07:27:00.0276] TabAtkins: I think we may have to drop RegExp patterns. Even if we resolve the issue with `is`, I think anything involving a RegExp literal is going to be problematic. [07:27:49.0122] Why so? [07:28:03.0354] there's lots of ways to have them without the problems [07:28:14.0737] we could require they have some kind of bounding characters or something. [07:28:22.0181] regexes are very important to have. [07:28:28.0214] Everything starting with `/` is suspect [07:29:08.0320] > <@ljharb:matrix.org> regexes are very important to have. I don't disagree, but they are at least achievable with extractors. [07:29:59.0276] > <@rbuckton:matrix.org> Everything starting with `/` is suspect so let's find another character for it to start with. we could require wrapping parens, or something [07:30:06.0775] They could also be handled via some other syntax, like `when like "(?i:\w+)"` [07:30:50.0813] sure. i don't think regexes are the primary issues we need to resolve rn [07:31:00.0603] > <@ljharb:matrix.org> so let's find another character for it to start with. we could require wrapping parens, or something Maybe, but I still don't consider them to be MVP as there are workarounds without them. [07:31:33.0087] dminor's feedback seems opposite to yulia's feedback; and waldemar is pointing out that binary keyword operators may not be possible. these seem worth focusing on [07:32:01.0889] > <@ljharb:matrix.org> it's an argument for having `is` go first, and `match` as the follow-on Well, to me `match` is the core of pattern matching, not `is`, I'm not convinced we need anything more. I'm happy to be convinced otherwise, but I would like to see an argument made for why a `match` statement is not sufficiently powerful for JavaScript. [07:32:08.0612] > <@ljharb:matrix.org> sure. i don't think regexes are the primary issues we need to resolve rn After plenary I'm going to take a closer look at all of the cover grammars to ensure things like `is`, `void`, `using` and `await using` all play nice together. I think choosing something like `~=` would just be kicking the can down the road. [07:33:04.0499] dminor: i like `is` on its own, but i definitely am happy with just having `match` - again, we created it in response to yulia's and the spidermonkey team's feedback. [07:33:41.0709] Though that may mean I have to drop `void` in _AssignmentPattern_, which may be for the best. The proposal _is_ called Discard _Bindings_... [07:33:43.0350] I realize Yulia and I are not in complete agreement about this, I'll chat with her about it. [07:33:58.0063] so it'd be really helpful to have yulia in these discussions to ensure her viewpoint is addressed [07:36:29.0288] I would very much like to have `if(x is Some(let y)) { }` and `node is Binary(let left, "===", let right) && doSomethingWith(left, right)` [07:36:48.0626] Please take what I've said so far as my personal opinion, not the SpiderMonkey team's. We'll be meeting next week, I'm hoping we can come to an internal consensus about pattern matching then. [07:38:10.0441] I think it would also help if we can pare down the pattern syntax to an MVP and pursue extending the syntax further in follow-ons, much like Iterator helpers has done. [07:39:02.0181] Re: my thoughts on the epic. we don't have to have is -- that wasn't my intention. `is` was meant to be illustrative of what a smaller proposal might enable [07:39:29.0100] * Re: my thoughts on the epic. we don't have to have `is` -- that wasn't my intention. `is` was meant to be illustrative of what a smaller proposal might enable. The same re the discussion on `let`/`const` [07:40:08.0916] i would be very happy if we first went with extractors and landed the custom matcher there. And then moved forward with match, and then the pattern matching DSL [07:40:30.0197] This is the main thing i was communicating with the epic: this proposal is too large and we need to think about it in smaller chunks [07:40:37.0421] That is consistent with what Dan is saying [07:40:41.0387] I think I'm fine with `is` being a follow on, but the semantics of `is` have implications on the design of this proposal that we must keep in mind. [07:41:35.0569] > <@yulia:mozilla.org> This is the main thing i was communicating with the epic: this proposal is too large and we need to think about it in smaller chunks tbh tho this feels like if someone suggested Temporal ship one type at a time [07:41:48.0299] One question I would ask is, are those semantics what we want to preserve, or is there an underlying concept that we can iterate on. I know waldemar had concerns with infix keywords, and i think we should come to a general understanding of what would be preferrable [07:41:51.0999] "large" isn't inherently a problem on its own; some things are just large [07:41:59.0152] rather than designing around a preconception [07:42:08.0380] temporal should have been split up as well [07:42:28.0278] the situation with temporal being endlessly stuck hasn't been great [07:42:29.0966] i agree it's incredibly large, but i don't see how it could have been viable split up. [07:42:54.0173] There is a core set of pattern mechanics that is an absolute MVP, there are many mechanisms that _aren't_ MVP despite the importance various champions put on them. For example, I find relational patterns much more important than regex literal patterns, but both are not MVP. [07:42:59.0553] * There is a core set of pattern mechanics that is an absolute MVP, there are many mechanisms that _aren't_ MVP despite the importance various champions put on them. For example, I find relational patterns much more important than regex literal patterns, but neither are MVP. [07:43:55.0258] Postponing relational patterns would mean holes in the syntax for corner cases we find important, but they don't break the proposal by not having them immediately. [07:44:01.0905] i think you need to start with the ideal that it can be split up, because i think the reason we haven't developed an understanding of a smaller core with principles guiding future design is because we can't align on the principles [07:44:33.0573] That said, `is not in` and `is not instanceof` are valuable enough that they already have a competing proposal at stage 1 [07:44:45.0105] that doesn't mean we can only do this by designing everything up front, we should get past the impass on principles. [07:44:58.0450] certainly there's a lot of differing opinions in committee about how a proposal should be designed :-) [07:45:20.0473] * certainly there's a lot of differing opinions in committee about how a proposal should be designed and developed :-) [07:45:26.0289] im sorry i don't have more time for this, but i do trust dan's leadership on this proposal. he represents the current spidermonkey consensus [07:47:34.0303] regarding the epic and the stuff i suggested, they were really suggestions to try and illustrate / bring discussion. It wasn't meant as "you have to include this or we will block it". The block was on complexity. I was trying to help but i think my message was lost [07:48:24.0640] I've been struggling with this because every time i ask for the proposal to be considered in smaller parts, i am told it is impossible, so i tried to demonstrate it but that backfired with the proposal becoming more complex and incorporating things I had meant as examples [07:48:44.0548] * I've been struggling with this because every time i asked for the proposal to be considered in smaller parts, i am told it is impossible, so i tried to demonstrate it but that backfired with the proposal becoming more complex and incorporating things I had meant as examples [07:49:16.0853] * I've been struggling with this because every time i asked for the proposal to be considered in smaller parts, i was told it is impossible, so i tried to demonstrate it but that backfired with the proposal becoming more complex and incorporating things I had meant as examples [07:51:49.0738] I would propose we consider the following as the MVP: - irrefutable `match (value)` - literal constant patterns - prefix numeric unary patterns - member reference patterns - extractors - object patterns (`{}`) w/ property patterns (`a: b`/`[x]: b`) and rest (`...`) - exhaustive array patterns (`[]`) w/ elision and rest (`...`) - `and`/`or`/`not` patterns - grouping patterns - variable patterns - discards (via either `void` or `let _`) - `if` patterns I think that's the minimal set of pattern matching that is necessary for it to be usable. Maybe we also add `in` relational patterns to cover `is not in`. Anything else is follow on. [07:51:56.0226] > <@yulia:mozilla.org> that doesn't mean we can only do this by designing everything up front, we should get past the impass on principles. after this redesign, most of the content can be dropped, but they're included in the big picture so I can make sure they're work well together (if we have to ship them in multiple batches). [07:52:54.0520] there are a lot of notes explaining this [07:53:12.0645] > <@rbuckton:matrix.org> I would propose we consider the following as the MVP: > - irrefutable `match (value)` > - literal constant patterns > - prefix numeric unary patterns > - member reference patterns > - extractors > - object patterns (`{}`) w/ property patterns (`a: b`/`[x]: b`) and rest (`...`) > - exhaustive array patterns (`[]`) w/ elision and rest (`...`) > - `and`/`or`/`not` patterns > - grouping patterns > - variable patterns > - discards (via either `void` or `let _`) > - `if` patterns > > I think that's the minimal set of pattern matching that is necessary for it to be usable. Maybe we also add `in` relational patterns to cover `is not in`. Anything else is follow on. what does this suggestion drop? [07:54:49.0291] * what does this suggestion drop? (regexes, obv, but im hoping for a list) [07:54:54.0166] `is`, regexp literal patterns, `<`, `<=`, `>`, `>=`, `==`, `!=`, `===`, `!==`, `instanceof`, `has`, `hasOwn`, `{ a?: b }`, any kind of potential shorthand `{ a }` pattern (can't recall if that's in there) [07:55:25.0281] it is [07:55:49.0856] `hasOwn`, as much as i want it, isn't its own ergonomic check in the language, so i can accept that one being a follow-in [07:56:27.0551] `in` and `instanceof` seem like good follow-ons because the semantics are 100% fixed; that's also why it seems like an obvious initial inclusion tho [07:56:31.0553] I think there were some other optional things as well, plus some reserved things like `` `${let a}` `` (we should still reserve it, but don't need examples of potential uses in the spec text) [07:56:53.0821] `instanceof` is less motivated since `x is C` and `x is not C` are mostly sufficient. [07:56:57.0207] relational patterns i agree can be added later, altho the equality comparisons maybe should be kept [07:57:09.0993] `in` is very well motivated, IMO. [07:57:16.0445] why drop `{ a }`? [07:57:35.0790] I'd rather punt on equality. It handles a narrow corner case. [07:58:24.0816] what are the semantics of `{ a }` in a pattern? My expectation would be "check if subject has a property `a` whose value must equal the value of the identifier reference `a`". [07:59:00.0370] Others might interpret `{a}` as being like `{a: let a }`, which it's not. Instead, they can use `{ a: a }` or `{ a: let a }`. [07:59:07.0644] yes [07:59:17.0721] invoking the matcher protocol as relevant [07:59:32.0335] > <@ljharb:matrix.org> invoking the matcher protocol as relevant That doesn't seem practically useful. [07:59:35.0457] and `{ let a }` would be the with-binding shorthand form [07:59:52.0973] I also think that, despite its convenience, we might want to postpone `{ let a }` and just have `{ a: let a }`. [08:00:27.0257] It's definitely more convenient, so hopefully it would have quick turnaround as a follow-on proposal. [08:00:47.0607] But it allows us to further pare down the proposal to the absolute MVP. [08:01:03.0808] and with this simpler featureset, would the grammar concerns and complexity concerns that have been voiced be resolved? [08:01:46.0781] * and with this simpler featureset, would the grammar concerns and complexity concerns that have been voiced be resolved? (in theory, obv, until the folks that voiced them can confirm) [08:02:19.0721] and we have 20 follow-ons [08:02:22.0492] I think it addresses the grammar concerns because we're not including the things with ambiguous parse. `is` and regexp literals were behind waldemar's concerns. [08:02:40.0276] > <@jackworks:matrix.org> and we have 20 follow-ons Sure, so has iterator helpers, and it's been fairly successful at getting them adopted. [08:03:44.0543] If we shoot for the moon now, we won't get there. Start with the bare bones version of the proposal, get that to Stage 4, and then propose enhancements and features. Some may be individual, some may be grouped together. [08:04:23.0625] Once the base syntax and semantics are in the language, its far easier to argue for QOL improvements. [08:04:30.0555] given the many inadequacies of the max/min approach with `class`, i'd find it sad to go in that direction, but you might be right. [08:05:44.0164] I do to, but pattern matching *is* a major syntax change. As it stands its far too intimidating. [08:09:26.0130] Extractors and `if` patterns let us work around missing functionality, at least. It's easier to argue for `> 1` as a QOL improvement over `let a and if(a > 1)` than it is to propose both at the outset. [08:09:37.0193] > <@ljharb:matrix.org> given the many inadequacies of the max/min approach with `class`, i'd find it sad to go in that direction, but you might be right. max/min class is a disaster and I don't want repeat it on pattern matching. the way to solve this, is to design all possible follow-ons we can think of and make sure they work good together or not together, then we can cherry pick some. I think we're currently doing this 2024-04-29 [07:51:42.0607] Are we meeting today? I still haven't had time to read over all the discussion that happened at/around plenary [07:52:57.0723] I think the big thing to discuss is whether/how to pair down the proposal to an MVP and a series of follow-on proposals to make it more palatable to the committee. [07:55:40.0288] Oh, I could definitely use an update on the details if what pushback we received [07:56:25.0401] * Ok, I could definitely use an update on the details if what pushback we received [07:57:26.0968] IIRC, we didn't present last plenary, so most of the feedback came from comments in this channel following the extractors proposal. [07:57:57.0938] Yeah, which I missed and don't want to scroll back to if I don't have to 😃 [07:58:15.0518] I had some high stress spec work going on for a week or so [08:01:05.0536] I've joined the call if you want to discuss. The comments aren't too far back in the history [08:01:32.0481] Yup joining now, had to negotiate who was doing what in the home office [08:02:08.0252] Omfg I hate zoom so much [08:03:58.0504] I’m running a bit late but will be there within the next 10 [08:16:00.0149] https://matrix.to/#/!XyZDxqjPFLRXDgUzhD:matrix.org/$jm0vstZtVQGMLjuluEMkTY0d_6HwfPXnyX5AyKA3nEs?via=matrix.org&via=mozilla.org&via=igalia.com [08:16:20.0474] ^^^ mvp ideas [08:17:08.0017] * I would propose we consider the following as the MVP: - exhaustive `match (value)` - literal constant patterns - prefix numeric unary patterns - member reference patterns - extractors - object patterns (`{}`) w/ property patterns (`a: b`/`[x]: b`) and rest (`...`) - exhaustive array patterns (`[]`) w/ elision and rest (`...`) - `and`/`or`/`not` patterns - grouping patterns - variable patterns - discards (via either `void` or `let _`) - `if` patterns I think that's the minimal set of pattern matching that is necessary for it to be usable. Maybe we also add `in` relational patterns to cover `is not in`. Anything else is follow on.