Bob Nystrom

> I don't think we should expect folks to rewrite every single line of code to use pattern-matching instead. I'd expect pattern matching on Maps to be very rare. >...

I've updated the proposal to make map patterns check the length. This makes them default to being "strict", and I intend to add support for `...` syntax to disable that....

I'm definitely writing the *proposal*, but it's usually @eernstg who translates that into the official language spec.

> If a class implements a `Destructure_n` interface, then isn't _that_ how it specifies how it should be restructured? For positional fields, yes. That's a good point. But the current...

> Maybe, instead of _implementing_ `DestructureN`, it should _return_ a `DestructureN` in a method? We could make it even simpler than that since records with positional fields are already a...

> In general, I'm against introducing a new way to deconstruct objects. Just use getters! (And consider `operator[]` a getter for this purpose, just like we treat `operator[]=` as a...

> Magically interpreting a class with `length` and `[]` getters seems more on the Python side (with `__len__` and `__getitem__`) than Dart This is only for list patterns like: ```dart...

> > * If the return type of the method is non-nullable, then the extractor will > > always match, so this `extract()` method can be used as a binder...

> That's probably too ambitious (would make more sense for a language where functions were always unary and tuples were built in from the start, like ML). Yeah, I think...

I'm definitely interested in extending extractor patterns to invoke other members and potentially chains of members. However, this also takes up pattern grammar space and I want to be sure...