Two new draft pattern matching JEPs

[Maurizio Cimadamore]

Looks good - some comments below (I apologize if some of these have been 
raised elsewhere):

## Patterns in switch

* In the general intro, maybe you could link this:

https://bugs.openjdk.java.net/browse/JDK-4032356

or this:

https://bugs.openjdk.java.net/browse/JDK-7127722

Which are all instances where users wished they had a more general way 
of switching on their hands (some of these are old, some of these were 
triggered, predictably, after Java 7 added support for String in switch).

* the syntax `case Foo, null` is nice, but the JEP doesn't say what 
happens if you use that twice - there seems to be an aspect of 
non-determinism if multiple case labels like these are alllowed? Ah - I 
see - it's in the well-formedness section. I think a fly-by comment on 
this would be helpful in the general description, as otherwise this 
feature looks more general than it is (e.g. it almost looks like a 
?String type, which I know it's not).

* New pattern forms (e.g. guards) - this nicely complements the feature 
set described in the JEP - but I guess it's worth considering if guards 
shouldn't live in their own JEP (e.g. use same approach we followed for 
array and record patterns), as I can imagine a lot of use cases covered 
even w/o guards (simple type cases statement such as the one mentioned 
in the JBS issue above).

* The fact that you can't mix between patterns and constants in a switch 
seems to belong more in well-formedness than in "Enhanced type checking 
of switch" ?

* "The possibility of falling through a switch label that declares a 
pattern variable must be excluded as a compile-time error." - again, 
this seem well-formedness? I understand that the discussion is very tied 
to scoping - but the issue I have with the JEP as it stands is that I'd 
expect to find, inside the "well-formedness" section a comprehensive set 
of rules which tell me what I can and cannot write - right now it just 
contains a _subset_ of all the rules, which are then defined in 
different sections. So take this mostly as an editorial comment.

* Future work - shouldn't this mention the other JEP, rather than 
speaking vaguely of "deconstruction patterns" ?

## Record Patterns and Array Patterns

* Array patterns; It seems like we could do more here. One issue is that 
we can only match the beginning of an array - fine, maybe we'll add more 
in the future to deal with this. The other, more important (IMHO) issue, 
is that the language already gives Iterable a special treatment in for 
each loop. That is you can use an enhanced for loop using an array 
source, or an Iterable source and they both work. Here we give arrays 
precedence, even though in reality there's a lot of code which will just 
be using collection. That said, I believe one of the impediment to have 
an Iterable-variant is associated with the fact that there's no syntax 
to appeal to (and we don't want to make a new one until we have a story 
for collection literals).

In other words, maybe this is all we can do and for good reasons, but 
maybe the JEP should clarify some of the "why nots" here?

* Future work - I think here we should mention a way to declare a local 
variable as a pattern, without an if/switch - e.g.

__syntaxbikeshed Point(var x, var y) = point;

Cheers
Maurizio





On 18/02/2021 12:33, Gavin Bierman wrote:
> Dear all,
>
> The next steps in adding pattern matching to Java are coming! I have drafted two new JEPs:
>
> - Nested Record and Array Patterns: https://bugs.openjdk.java.net/browse/JDK-8260244
>
> - Pattern Matching for switch: https://bugs.openjdk.java.net/browse/JDK-8213076
>
> We split them up to try to keep the complexity down, but we might decide to merge them into a single JEP. Let me know what you think.
>
> Draft language specs are under way - I will announce those as soon as they are ready.
>
> Comments welcome as always!
>
> Thanks,
> Gavin