Next up for patterns: type patterns in switch

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Guy Steele" <guy.steele at oracle.com>, "John Rose" <john.r.rose at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 12 Août 2020 22:05:02
> Objet: Re: Next up for patterns: type patterns in switch

> Since I am always the one saying "state your concern, not your
> solution", let me frame this:
> 
>> But i still think having a keyword to signal that a pattern (not a
>> case) is total is better than letting people guess.
> 
> From this I take away that (a) the rules we've proposed for totality vs
> not are mostly OK in terms of their expressiveness and their defaults,
> but (b) you are worried that it is too subtle for Java developers to
> determine whether a given sub-tree of a pattern is total on the part it
> is matching, so (c) you would like some additional assertions to say
> "this is total, error if I'm wrong". These assertions benefit would both
> the writer (to catch errors) and reader (so totality snaps off the page.)
> 
> Do I have it right?

yes, you can add (d) the keyword also makes the fact that a pattern is total a local property so actions at distance that change the pattern from total to non total will lead to an error.

> 
> But isn't the "switch is total" kind of the half-brother of this story,
> too?  Since statement switches might be total or partial, stating the
> intent would be useful in the same way, right?  (To be clear, I think
> this is two separate issues, but they are related.)

yes,
there is no problem with the expression switches and statement switch with one total pattern at top-level (if there is a keyword for pattern totality), but if a statement switch is exhaustive it can become partial after a change and there is currently no way to express that you want to keep the statement switch total.

Rémi