New [draft] JEPs for Pattern Matching

[Stephen Colebourne]

It seems like this JEP didn't get much direct feedback at the time.

Introducing pattern matching gently seems like a reasonable goal. However I
have some specific concerns regarding the semantics of using patterns in
if/else.

When used in a switch, patterns are generally clear, dropping from one
clause to the next:

 switch (foo) {
   case Integer i -> // i now in scope
   case Double d -> // d now in scope
 }

However, there is not yet a firm statement on how the above generalises
when there is an additional test. For example, one floated syntax appeared
to be:

 switch (foo) {
   case Integer i when i > 0 -> // i now in scope
   case Integer i -> // i now in scope
   case Double d -> // d now in scope
 }

(IMO a `when` clause is clearer than some other alternatives). Without
clarity on the semantic choice for additional tests of the pattern ("when"
clauses or && or something else), it feels premature to pursue if/else
statements with patterns.

The basic proposed `instanceof` syntax is clear enough:

 if (foo instanceof Integer i)  // i now in scope

But this gets much more complex when there are multiple predicates,
negations and else clauses. It is certainly possible to write some obtuse
code [1].

My feeling is that building on `instanceof` and allowing it to apply
patterns anywhere could well be the wrong direction of travel. It doesn't
seem completely unreasonable to restrict pattern predicates, rather than
allowing them everywhere. With this semantic approach, the `case` keyword
seems a much better syntactic fit. This allows a smooth mental model from
switch to if/else:

 if (foo case Integer i when i > 0) // i now in scope
 else if (foo case Integer i) // i now in scope
 else if (foo case Double d) // d now in scope

Semantically, the if statement would be allowed to hold a boolean
expression as now, _or_ a single case-when pattern. You would not be
allowed to negate the case-when, nor mix the case-when with any other
boolean expression. These simpler semantics appear to provide a much more
straightforward mental model that avoids a lot of the complexity of simply
adding pattern semantics to `instanceof` [2]

Does Java need patterns to be usable as arbitrary boolean expressions?

thanks
Stephen

[1]
http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-December/000915.html
[2] http://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html


On Mon, 29 Oct 2018 at 13:51, Gavin Bierman <gavin.bierman at oracle.com>
wrote:

> In the context of the new rapid release model for Java, we’d like to break
> up the proposed pattern matching features so we can deliver them to you
> faster.
>
> To that end, we’ve rewritten JEP 305 to now cover adding pattern matching
> to just instanceof:
>
> https://bugs.openjdk.java.net/browse/JDK-8181287
>
> And there’s a new draft JEP that covers adding pattern matching to switch
> (and some other possible extensions):
>
> https://bugs.openjdk.java.net/browse/JDK-8213076
>
> Essentially this is just dividing the old pattern matching JEP into two
> parts.
>
> Comments welcome!
> Gavin
>
>
>
>