Updated pattern match documents

[Tagir Valeev]

Hello!

Regarding dominance of the combination of patterns. The semantics document says:

> This includes patterns that are dominated by prior case labels, as well as case labels that are dominated by combinations of prior case labels -- such as a T? pattern that follows a nullable pattern and a T pattern.

I think, this part requires clarification. Some interesting cases:

switch(boolValue) {case true:case false:case _:break;} -- is case _ a
compilation error? What if case _ is changed to default?
switch(boxedBoolValue) {case true:case false:case null:case _:break;}
-- the same question

assuming enum Direction {UP, DOWN} and Box(Direction)
switch(box) {case Box(UP):case Box(DOWN):case Box b:break;} -- I
assume that case Box b is allowed here as it can match Box(null). Even
if Box(Direction) constructor requires that Direction is not null,
compiler cannot know this. Or can?
switch(box) {case Box(UP):case Box(DOWN):case Box(null):case Box
b:break;} -- what now? Do we consider the combination of Box(UP),
Box(DOWN) and Box(null) as exhaustive?

Also what about combinations of several fields? Assuming
TwoFlags(boolean, boolean):
switch(twoFlags) {case TwoFlags(true, _):case TwoFlags(_, true):case
TwoFlags(false, false):case TwoFlags t:break;} -- here all
combinations are covered by first three patterns, so TwoFlags t cannot
match anything. Will it be reported? What if we have ten enum fields?
Will compiler track all covered value combinations and issue an error
if it's statically known that some pattern is unreachable? I'm not
sure about computational complexity of such tracking in common case.

With best regards,
Tagir Valeev.



On Sat, Sep 8, 2018 at 1:41 AM 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.
>