| 00:06 | <TabAtkins> | Oooh, that pattern-matching PEP is making many of the same choices we appear to be settling on for JS, nice. |
| 00:13 | <TabAtkins> | Big difference being that we're planning on separating out destructuring and class-based matching, while they're sticking them together, implicitly destructuring with either a sequence or mapping destructure written like a constructor call. |
| 00:17 | <TabAtkins> | (That ends up being quite weird imo; it's designed to let you make a match clause *look like* a constructor, but it actually matches off of the returned value, which can have no relation whatsoever to how you'd actually construct a value.) |
| 00:17 | <TabAtkins> | But still, otherwise it mostly accords with our thoughts, nice. |
| 00:19 | <TabAtkins> | Hm, actually the PEP's inability to match based on an expression result is problematic; you can't, say, match against a range. |
| 00:20 | <bakkot_> | other big difference is that it's statement-position-only |
| 05:02 | <devsnek> | ljharb: i think your changes to asyncfromsynciteratorprototype changed the length properties of the methods, that's expected right? |
| 05:03 | <devsnek> | s/expected/intended/ |
| 05:05 | <ljharb> | yes, since the methods aren’t observable it’s non-normative |
| 05:06 | <devsnek> | ah yeah true |
| 05:09 | <TabAtkins> | statement-position only is very Pythonic, I don't consider that to be a significant difference here (that is, not something we should draw conclusions about JS from) |
| 05:10 | <rkirsling> | agree |
| 05:11 | <rkirsling> | in a way that Rejected Ideas section is some of the most interesting content |
| 14:05 | <jackworks> | rbuckton: https://github.com/rbuckton/proposal-enum/ would you like to move this to stage 1? I'd like to see ADT enum comes true 🌟 |
| 22:03 | <mpcsh> | jackworks: I'd also love to see this. rbuckton if you'd like to revive this I can lend a hand |