I like that there is this left-to-right flow. I think it’s a bit nicer to read than if-let ordering where the pattern comes before the thing it will be matched against. I think it’s also good for ocaml-style constructor disambiguation, which tends to go in lexical order.

Another nice aspect of making guards a less special case is that it avoids complexities in deciding if a binding is unused. I believe this logic was a source of lots of compiler warning bugs in ocaml.

This syntax doesn’t seem to solve the following problem with matching where there are two paths to the same binding, (say you have an option in one branch but it isn’t optional in the other, and maybe you’d like to handle both cases with the same code. Currently you can do that with a match (match …) with … pattern.

I worry that the semantics around exhaustiveness and mutable values may be confusing, though I guess OCaml already has that problem:

  type t = { mutable x : bool }

  let n = function true -> 1 | false -> 0

  let f t =
    match t with
    | { x = false } when ( t.x <- true; false) -> -1
    | { x } -> n x * 2 + n t.x

What does t { x = false } return? Similarly if you changed the second case to be two cases instead of binding x?