How to implement a record de-constructor ?

[Brian Goetz]

Your point is noted that the notion of a record deconstructor is a 
simpler case of general matchers.  However, is there an immediate need 
for explicit record deconstructors, since the compiler can generate the 
obvious one?  And if there is an immediate need, wouldn't it likely be 
motivated by the need for some of the more advanced features 
(partiality, snapshotting, etc)?

> if a de-constructor is inlined by the VM the same way getter is inlined by the VM, i.e. most of the time,
> and if the de-constructor has no side effect (otherwise you have bigger problem that just a performance issue) then the VM will remove unused computation,
> share common sub-expressions, etc.

I would love to buy this, but I don't.  The expensive actions of dtors 
are likely to be allocating and copying stuff; even if the results are 
unused, there are still many reasons why the JIT might not elide the 
allocation and copying.