[External] : Re: Can pattern methods be total ?

[Brian Goetz]

> I've certainly a more runtime oriented approach, everything the runtime needs to link in order to perform pattern matching are what i call pattern methods.

So, there's really three layers here: the language model, the runtime 
model, and the translation scheme.  From a runtime perspective, 
deconstructors can translate to static methods (we don't need a new VM 
concept for this.)  We need to keep our eye on the translation and 
runtime model, but I'm pretty confident we have multiple efficient 
translation schemes available to us, so I'm focused right now on the 
language model.  Things like "deconstructors are total" can (like 
checked exceptions) be a language fiction that is erased away in 
translation, if we like.

> for records, the compact deconstructor doesn't have to specify the bindings because they can be derived from the declaration.

Not so fast!  Yes, for a record _without an explicit canonical 
deconstructor_, we can derive a canonical deconstructor which delegates 
to getters (just as we can derive a canonical constructor.)  But, just 
as you can "override" the canonical constructor with your own (subject 
to rules), users should be able to similarly "override" the canonical 
deconstructor.

Of course, by that time, there will exist records in the wild without 
deconstructors, so we have a compatibility challenge.  One way to 
resolve that challenge is to indirect the lookup through indy/condy, so 
that we can reflectively look at the record class and see if it has an 
appropriate member, or whether we have to synthesize one.