Hi Brian, i'm glag that "deconstructor" can now be virtual.
Can you point to where in the doc you got that idea? A deconstructor is the dual of a constructor. A constructor is not a virtual member, nor a static member; it takes a receiver, but is not inherited and cannot be overridden. Deconstructors are exactly the same way. There will be other kinds of patterns -- analogous to static and instance methods -- but they're different from deconstructors. This doc alludes to their existence, but doesn't yet give examples. That's for another doc.
I think there is a missing discussion about what a case method can return, it can return something saying no match, it can return something saying there is a match and here are the values.
No (but I understand why you assumed this, you are skipping ahead to the exciting part of the story.) Some patterns are _total_ (always match target of a given type) and some are _partial_ (imposing additional conditions on matching). I am currently assuming "deconstruction patterns are always total" (this is probably only 99.99% true, but a reasonable simplifying assumption) so there's no provision for saying "nope, this does not match" _for deconstructors_. The other kinds of declared patterns (static and instance patterns) surely need some way of saying "no, it didn't match" (and there's many options for how to surface this), and while this document alludes to the existence of these patterns, there's more coming. This is not the "mechanics" document, it is this "10,000 foot view of the object model" document.
One question is how the values are associated to the bindings, in the pattern, you have a notion of order, i.e. Point(var x, var y), x is the first binding and y the second, but in your proposed syntax, there is no notion of order, you associate a name to a value.
Correct. There are many different ways to model this. (I know you're partial to the "return a tuple" model.) In the examples I gave for illustrative purposes, I have turned the knob mostly towards the "imperative", to the point where a deconstructor body is almost literally the mirror image of a constructor body. There are other ways to do it, and there's a conversation to be had there, but that wasn't the conversation I was trying to elicit with this document. This document is entirely about "what is the role of a pattern in the language and object model", because, if we can't agree on that, then the syntactic concerns are irrelevant.
There's more coming which will dive into the mechanics and user model that you'd like to talk about here, but I'm still not quite ready for that, not until we are on the same page with the big-picture questions.
