Updated pattern match documents

[Stephen Colebourne]

Nice documents. A question and a few thoughts.

Why can 'default' not also capture null?
Since null is not currently allowed in switch, the incompatibility is
not immediately obvious.
If the plan is to allow nulls into switch based on the presence or
absence of a null accepting pattern, that does make me uncomfortable
(too much action at a distance in a large switch).

Use of ? nullable types to allow null
I'm broadly happy with this - the ? reads well. I'm less comfortable
that this will be the only place in the language that supports
nullable types. While fully aware of feature creep, I don't want
nullable types to stick out like a sore thumb either. Since records
are an entirely new feature and closely associated with pattern
matching, it is very appealing to use nullable types for the fields of
a record. In fact, I'd go further - any type that wants to have a
deconstructor/extractor should be written in terms of nullable types.

Scoping and instanceof
While the rules are no doubt exactly what makes logical sense, they
are undoubtedly complex. I think it is fair to ask whether they are a
step too far. The simple examples (p instanceof Point(x, y) && x > 0
&& y > 0) are obvious enough, but some of the other forms that can be
written are seriously obtuse. As such I have some doubts about
associating patterns with the existing 'instanceof' (or perhaps it is
associating && and || with patterns in if statements). The
occasionally mentioned 'when' clause would separate the two parts and
has the potential to be clearer if it allows limits to be placed on
the associated expressions, for example: if (p case Point(x, y) when x
> 0 && y > 0) {...}  It would be very easy to explain the mapping from
'switch' to if/else chains with the reuse of 'case', and I think
'case' will read better with more complex patterns. Moreover, I'm yet
to be convinced that pattern-style expressions belong everywhere that
an expression can go, thus reusing 'instanceof' doesn't entirely
appeal to me.

Extractor syntax
I'm unconvinced about the syntax used in the documents for extractor
methods. When invoking it, the caller passes no parameters, yet the
syntax suggests that it has parameters. I could suggest alternative
syntaxes, but for good behaviour I won't.

Stephen


On Fri, 7 Sep 2018 at 19:41, Brian Goetz <brian.goetz at oracle.com> wrote:
>
> I've updated the documents regarding pattern matching, and uploaded them
> here:
>
> http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html
> http://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html
>
> The first document is an update of a previous document (old version
> available here:
> http://cr.openjdk.java.net/~briangoetz/amber/pattern-match_1.html), and
> outlines the general arc of the feature and general motivation.
>
> The second captures the discussions we've had regarding the messy
> details of typing, scoping, nullability, shadowing, etc.  I think we've
> made a lot of progress on these.
>
> We would not implement this all at once; we'd proceed incrementally,
> probably starting with type patterns in `instanceof`, and then
> proceeding to `switch` or to deconstruction patterns.
>
> Please review and comment.
>