Pattern matching: next steps after JEP 405

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, May 18, 2022 9:18:01 PM
> Subject: Pattern matching: next steps after JEP 405

> JEP 405 has been proposed to target for 19. But, it has some loose ends that I'd
> like to refine before it eventually becomes a final feature. These include:

[...] 

> - Varargs patterns. Records can be varargs, but we have an asymmetry where we
> can use varargs in constructors but not in deconstruction. This should be
> rectified. The semantics of this is straightforward; given

> record Foo(int x, int y, int... zs) { }

> just as

> new Foo(x, y, z1, z2)

> is shorthand for

> new Foo(x, y, new int[] { z1, z2 })

> we also can express

> case Foo(var x, var y, var z1, var z2)

> as being shorthand for

> case Foo(var x, var y, int[] { var z1, var z2 })

> This means that varargs drags in array patterns.
Thinking a bit about the varargs pattern, introducing them is not a good idea because a varargs record is not a safe construct by default, 
- varargs are arrays, and arrays are mutable in Java, so varargs records are not immutable by default 
- equals() and hashCode() does not work as is too. 

The record Foo should be written 

record Foo(int x, int y, ... zs) { 
Foo { 
zs = zs.clone(); 
} 

public int[] zs() { 
return zs.clone(); 
} 

public boolean equals(Object o) { 
return o instanceof Foo foo && x == foo.x && y == foo.y && Arrays.equals(zs, foo.zs); 
} 

public int hashCode() { 
return hash(x, y, Arrays.hashCode(zs)); 
} 
} 

Given that most people will forget that the default behavior of a varargs record is not the right one, introducing a specific pattern for varargs record to mirror them is like giving a gentle nudge to somebody on a cliff. 

Note that, it does not mean that we will not support varargs record, because 
one can still write either 
case Foo(int x, int y, int[] zs) 

or 
case Foo(int x, int y, int[] { int... zs }) // or a similar syntax that mix a record pattern and an array pattern 

but just that there will be no streamlined syntax for a varargs record. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220520/5ea00bb1/attachment.htm>