Support or patterns in matches

[cpitclaudel]

Desired syntax:

datatype T = A(i: int) | B(j: int) | C(bool) | D

method Test(t: T) {
  match A
    case A(i) | B(i) => print i;
    case C(_) | D => print "";
}

[MikaelMayer]

How do you handle the second case, where it seems that you need a variable C(b) ? Would b be ignored then?

[cpitclaudel]

It was a typo, good catch; thanks! I was hoping to use that case to demonstrate that you could use _ :/

[MikaelMayer]

What about:

datatype XT = X_AORB(i: int) | X_OTHER

method Test(t: T) {
  match AORB(t)
    case X_AORB(i) => print i;
    case X_OTHER => print "";
}

function method AORB(t: T): XT {
  if t.A? then X(t.i) else if t.B? then X(t.i) else X_OTHER
}

[cpitclaudel]

There are a few problems with this alternative:

• It's longer than the original code
• It has a runtime cost.
• It doesn't scale: you have to define a new datatype and a new function to project the original one for each new match that groups constructors differently.

When you have tens of constructors, it's not really viable to do it this way, I think (and even for this specific example, I find the or pattern a lot more readable)

[cpitclaudel]

In the long term, we'd like to have support for fully general or-patterns, including or patterns nested inside constructors and or patterns including variables. Prior to doing this, we need to refactor the computation of pattern match decision trees, which currently is done during resolution.

For the first iteration of this feature, we'll support only top-level patterns with _, literals, and constructors — no variable bindings and no nested | patterns. Disallowing variables is the most important part, as it allows us to punt on tricky cases like the following:

datatype T = Nat(n: nat) | Int(i: int)

method M(t: T) {
  match t {
    case Nat(n) | Int(n) =>
      print n;
  }
}

method M'(t: T) {
  match t {
    case _ =>
      var n := if t.Nat? then t.n else t.i;
      print n;
  }
}