> From: "Brian Goetz" <brian.go...@oracle.com> > To: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Sent: Thursday, March 3, 2022 9:42:25 PM > Subject: Telling the totality story
> Given the misconceptions about totality and whether "pattern matching means > the > same thing in all contexts", it is pretty clear that the story we're telling > is > not evoking the right concepts. It is important not only to have the right > answer, but also to have the story that helps people understand why its right, > so let's take another whack at that. > (The irony here is that it only makes a difference at one point -- null -- > which > is the least interesting part of the story. So it is much sound and fury that > signifies nothing.) > None of what we say below represents a change in the language; it is just > test-driving a new way to tell the same story. (From a mathematical and > specification perspective, it is a much worse story, since it is full of > accidental detail about nulls (among other sins), but it might make some > people > happier, and maybe we can learn something from the reaction.) > The key change here is to say that every pattern-matching construct needs > special rules for null. This is already true, so we're just doubling down on > it. None of this changes anything about how it works. [...] > #### Let > This is where it gets ugly. Let has no opinions about null, but the game here > is > to pretend it does. So in a let statement: > let P = e > - Evaluate e > - If e is null > - If P is a covering pattern, its binding is bound to null; > - else we throws NPE > - Otherwise, e is matched to P. If it does not match (its remainder), a > MatchException is thrown (or the else clause is taken, if one is present.) It's not clear to me why a MatchException should be thrown instead of not compiling if not exhaustive. It's mean that there are remainders that does not lead to either a NPE or an error, do you have an example of such remainder ? Rémi
