How to implement a record de-constructor ?

[Brian Goetz]

> The issue is that there is no tuple in Java, so writing a de-constructor now is not easy.
Nor performant, because even though will soon have something like tuples 
(that's records), which makes it a lot easier to write, you still have 
to contend with boxing (until we have value records.)

> So we have two ways to deal with the implementation of a de-constructor:
> 1/ internally, toString/equals or hashCode implementation of a record are already using a form of de-constructor as an array of method handles

You'll recall this was the subject of my JVMLS talk last year.

But having a reasonable mechanics to translate to doesn't immediately 
give us a clue about how to write it in the language; surely we're not 
exposing method handles to the user.  And there are a host of 
complicating factors; composition (delegating from one matcher to 
another, such as the super matcher), partiality vs totality (some 
patterns always match on a certain type, which the compiler can reason 
about; others have dynamic conditions like "palindromic string"), 
laziness (ideally, matching Foo(var x, _) where the second component is 
ignored shouldn't cause the second component to be computed), eagerness 
(sometimes you want a matcher to eagerly compute a snapshot, for 
purposes of data consistency), shared computations (sometimes there are 
expensive shared computations between the "does it match" calculation 
and the "extract the components" calculation, which you'd like not to 
redo, but this conflicts with laziness), inheritance of matchers, 
overriding of matchers, overloading of matchers, overload selection, and 
more.  It's a complex topic.  I propose we wait on deep-diving on this 
until we've gotten some more of the basics onto more solid footing.