New [draft] JEPs for Pattern Matching

[Stephen Colebourne]

On Thu, 13 Dec 2018 at 01:33, Brian Goetz <brian.goetz at oracle.com> wrote:
> So, let’s back up.  Almost all of your note was about a solution, but what’s missing is what’s motivating you to propose this particular solution.  It’s almost always more useful to share your perception of a _problem_ than a proposed solution.  (Maybe the problem isn’t really a problem, in which case the solution isn’t needed.  Or maybe theres a better solution, but without a shared understanding the problem, we can’t really evaluate your solution.)  You alluded to the possibility of writing obtuse code — but, even if obtuseness were objective, the possibility that someone might write confusing code is not a reason to arbitrarily constrain the language.
>
> So, let’s start over.  What _problem_ you are concerned about?

I can see plenty of examples and motivating use cases for a single
pattern test in an if statement, with optional when and optional else.
The use cases for combining patterns, or negating them, seems weaker -
it doesn't happen in switch AFAICT (certainly I've never seen an
example where it has been proposed).

I think its right to question whether there really is enough
motivating use case to justify patterns *everywhere*, which is what is
implied by making them boolean expressions. Especially as the
implication of doing so is a whole heap of complicated rules around
the scope of the new variable.

I assume the following is either pointless or a compile error:
  boolean isString = obj instanceof String s;

What about this - is s in scope in the braces?:
  while (obj instanceof String s) { ... }

Or this - pointless, or error?:
 list.stream().filter(obj -> obj instanceof String s);

Pattern-tests as arbitrary boolean expressions opens up a whole range
of possibilities where the rules may not be instantly obvious. Maybe
its the right direction for Java, but I haven't seen anyone
questioning the implications or the need beyond the simple/obvious
examples. No one doubts the boolean expression approach is more
expressive, but I question the assertion that it has less complexity.


As a separate, and syntax only point, I think `case` is more readable
and more intuitive than extending `instanceof` whichever semantics are
adopted, in that a pattern is always preceeded by case (and also
instanceof implies a type on the RHS but not all patterns are types,
right?).

Stephen