Leaf Petersen

I filed a somewhat (but possibly not entirely) redundant issue on the same basic idea [here](https://github.com/dart-lang/language/issues/2402).

On the question of generics, we can definitely implement these either way: that is, given this example: ```dart class A { nonvirtual void show() { print(T); }; } void main()...

> With the extension method based approach, how would we handle this?: > > ```dart > class A1 { nonvirtual void m() { print('A1'); }} > class A2 { nonvirtual...

> Going in the other direction removes, and potentially _breaks_, abstraction. That's bad, we don't want to encourage breaking abstraction. I don't understand this. How does it break abstraction? >...

> A destructor ca neither provide no information which isn't already available through getters (in which case I think the destructor isn't really necessary _because_ we have getter matching patterns),...

> * 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 pattern. >...

> The fact that you can already do this to call class-defined transformation methods is a good observation. I still thing user-defined extractor functions/methods look nicer and feel more natural,...

@natebosch will investigate the feasibility of this.

Proposed specification [here](https://github.com/dart-lang/language/pull/2538).

We discussed this in the meeting this morning. There was fairly broad consensus that the current specification which uses a field on `Record` for an empty tuple, a required trailing...