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
