A peek at the roadmap for pattern matching and more

[Brian Goetz]

> We want a destructor, a destructor is a method that returns a list of values the same way a constructor takes a list of parameters.
> The way to represent that list of value is to use a record.

Yes, already been down that road, I did an entire sketch of this feature where we expose “anonymous records.”  It felt really cool — for about five minutes.  The conclusion of this exercise was that in this case, records are better as a _translation mechanism_ than a surface syntax.  So yes, the way to represent it is a record, but in the class file, not the language.  

> So we can already write a de-constructor with the current version of Java,

As you figured out, if you cast a deconstructor as a method with a special name, you say goodbye to deconstructor overloading.   And if you do make it magically overloadable, then it's magic, and you’ve lost all the benefit off pretending its a method.  You just moved the complexity around.  And again here comes that glass half empty feeling: “Why can I only do it with this method?”. Much better to recognize that deconstruction is a fundamental operation on objects, just like construction — because it is.  

> i should wuth by example a method minMax that returns both the minimum and the maximum of an array

>   public static (int min, int max) minMax(int[] array) {

Nope.  Not going there.  I went down this road too, but multiple-return is another one of those “tease” features that looks cool but very quickly looks like glass 80% empty.  More fake tuples for which the user will not thank us.  And, to the extent we pick _this particular_ tuple syntax, the reaction is “well then WTF did you do records for?”  Having records _and_ structural tuples would be silly.  We’ve made our choice: Java’s tuples are nominal.  

Worse, it only addresses the simplest of patterns — deconstructors — because they are inherently total.  When you get to conditional patterns (Optional.of(var x)), you want to wrap that record in something like an optional.  If the return value is fake, now you have to deal with the interaction of trade tuples and generics.  No thank you.  

Believe me, I’ve been down ALL of these roads.  

> the compiler will generate a synthetic record, so the generated code is equivalent to

The synthetic record part is the part I liked, and kept.

There’s room for an “anonymous tuple” feature someday, maybe, but we don’t need it now.  

I’m willing to consider the “record conversion” when we get to collection literals, but not now.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200813/52e63400/attachment.htm>