New pattern matching doc

Brian Goetz brian.goetz at
Sat Jan 16 13:34:58 UTC 2021

> Hah, synchronicity! Yes, I was drafting an email with a suggestion for
> something similar, although i used a __MATCH_OR_DIE expression form
> that looked like a cast, and an unchecked exception.
> Did I just imagine it, or was there a suggestion for something like
> this in the past?:
>    var Point(var x, var y) = ...

Close.  We have experimented with various forms of "imperative match".  
Our first attempt was something like:

     let P = e;

where P had to be total.  This was later refined to something like

     let P = e
     else { ... }

where the else block had to either throw, or assign to all the bindings 
in the pattern.

We later started to feel that (a) `let` was unnecessarily fussy, and (b) 
casting it like a statement meant that we lost some other 
opportunities.  So we shifted towards something like

     P = e

for suitably constrained patterns, on the observation that

     T t = e;

which is currently a local variable assignment, could equally well be 
interpreted as matching the type pattern `T t` to the expression.  So we 
could retroactively reinterpret `P = e` (at least for type and 
deconstruction patterns) as an imperative match, rather than a 
declaration-with-initializer, if we want.  That's nice, but that kind of 
forecloses on the else clause.

Regardless, the semantics here would be match-or-not, rather than 
match-or-die.  I think if you wanted match-or-die, you'd have to 
specifically ask for it somehow (such as a try- construct.)

More information about the amber-spec-experts mailing list