A peek at the roadmap for pattern matching and more

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 13 Août 2020 15:42:40
> Objet: Re: A peek at the roadmap for pattern matching and more

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

first why ? and second, my experience is the opposite, the more there is a difference between Java the language and the translation strategy the more it will bite you with corner cases. 

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

It's not magic, it's a translation strategy like the same way with bridges, you can have methods with the same name and different return types. 

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

But constructors are plain methods with some special bells and whistles (funny names, funny rules for the initialization of this and final fields, etc). 
Having a deconstructor being a method with several overloads doesn't strike me as very magic compared to a constructor. 

And you can not have several overloaded methods with different return types because Java like C doesn't force you to specify the return type of a method call. So unlike with a pattern where you provide the type, you don't provide the return type when you do a method call. 

>> 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?”

Records are the underlying type used by the tuple syntax. 
The tuple syntax is as its name suggest, just a syntax. From the semantics POV, it's an anonymous record, thus, not a structural type. 

You may use a record instead of an anonymous record, if you want to reuse the same record for multiple deconstructor, if i have several classes representing rectangular shape, i may want them to share the same record. 
It's really very similar to the difference between a method reference and a lambda or a classical class and an anonymous class. A record is explicitly named, it can have annotations, it can be serializable, implements interfaces, have it's own toString() etc. An anonymous record is the anonymous version of a record, where you don't care about the name or resource sharing (on record per deconstructor). 

> Having records _and_ structural tuples would be silly. We’ve made our choice:
> Java’s tuples are nominal.

But the syntax you are proposing for deconstruction is using the syntax of a _structural tuples_ . Here the glass is half empty, because why the deconstructor can have that feature and not any methods given that at the end a de-constructor is desugared as a method that return a record. As i said in my original mail. I agree with you that we don't want a _structural tuples_, but it's not, it's an anonymous record and restricted them only to deconstructor does not make make a lot of sens. 
I's like saying look this shinny anonymous record, deconstructor can use them but not regular methods. 

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

I don't see the issue here, where is the problem with the following code ? 
Optional<(int x, int y)> deconstructor() { 
return Optional.of( (this.x, this.y) ); 
} 

Maybe users will find the syntax weird ? But it's like any new feature ? 
I believe you are thinking that the type (int x, int y) is a tuple while technically it's an anonymous record, so from the type system POV it acts as a record, i.e. a nominal class. 

> 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 not suggesting to introduce an anonymous tuple, as you said above, we have decided to use record instead, a nominal type. 
I'm suggesting to introduce the concept of anonymous record, which is what the synthetic record is, because i see no point to restrict it only to deconstructors. 

> I’m willing to consider the “record conversion” when we get to collection
> literals, but not now.

To represent the couple key/value i suppose. 
I don't disagree, but i don't think it's wise to introduce the idea of a synthetic record without the notion of anonymous record, but we don't need a synthetic record for deconstructors, it's nice to have but not an essential part of the design. 

Rémi