[patterns] AND patterns, OR patterns, fall though

Brian Goetz brian.goetz at oracle.com
Sat Nov 4 22:20:44 UTC 2017

In theory, patterns can be combined with AND and OR to produce new patterns, if their target types and binding lists are compatible.  Note also that most fallthroughs (those where the case labels immediately follow other case labels, with no intervening statements) can be expressed as OR patterns.  

Some form of OR patterns are almost a forced move if we want to have expression switches with patterns:

    int numLetters = switch(s) {
        case "one", "two" -> 3;
        case "three" -> 5;

Because, while statement switches can simply repeat the labels:

    case "one":
    case "two":

this idiom looks pretty stupid if we try to transplant it to expression switches:

    case "one" ->
    case "two" -> wtf?

OR patterns give us much of what fallthrough gives us; the only difference is the ability to have intervening statements between the case labels.  Given that expression switches push us towards OR patterns, why not double down, using this for statement switches, and prohibit fallthrough for statement switches too?  This is simpler and covers what seem like the important cases.  

In theory, an OR pattern of P and Q would require that both P and Q are applicable to the static type of the target, and (in the most strict interpretation) have identical binding variable lists. 

Note that we have a form of OR patterns now, with multi-catch:

    catch (E1 | E2 identifier)

Though, this might not really be what we want an OR pattern to look like, as this looks like the OR of "E1" (no bindings) and "E2" (with bindings), which would fail our restriction on the binding variable lists being the same.  An OR pattern would more correctly be written (E1 e | E2 e).  (However, we could interpret “E1|E2 identifier” as a union type-test pattern if we wanted to unify catch with patterns.)

The big question is whether we need OR patterns at all, or whether this is merely an artifact of the switch statement.  For the matches expression, we can express ORs clearly enough without it:

    if (x matches P || x matches Q)

(and we need to support this anyway.)  If we used comma to separate patterns:

    case 1, 2, 3: 
    case Foo x, Bar x, Baz x:
    case Foo(var x), Bar(var x), Baz(var x): 

Is that clear enough?  Is that unambiguous enough?  If this works, this is nice because it works cleanly with existing constant switches too.  I think this is pretty good.  

So, concrete proposal:
 - Allow multiple patterns to be separated by commas in a case label;
 - Treat “case X: case Y:” as sugar for “case  X, Y:” in statement switches;
 - Impose the “same bindings” rule when multiple patterns are combined in this way;
 - Disallow fall through into patterns with binding variables. 

Note that we don’t have to create a new kind of switch here to prohibit fall through; we just don’t allow fall through into non-constant pattern cases.  

Note that Scala lets you OR multiple patterns together:

def matcher(l: Foo): String = {
  l match {
    case A() => "A"
    case B(_) | C(_) => "B"
    case _ => "default"
but I'm not sure whether this is really an OR on patterns, or whether this is a "feature" of match?  But, this seems a pretty questionable syntax choice, as:

scala> 1 match {
     | case 1 | 2 => "one";
     | }
res0: String = one

scala> 1 | 2
res1: Int = 3
So, even though 1|2 is an integer constant whose value is 3, "case 1|2" is an OR pattern.  

Similarly, its even less clear that we need AND patterns.  Though I could imagine wanting intersection type-test patterns, like:

    switch (lambda) {
        case Predicate p && Serializable: ...
        case Predicate p: ...

Are there compelling use cases for AND patterns that I’m missing?  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20171104/25d4f6f9/attachment-0001.html>

More information about the amber-spec-experts mailing list