> 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.
