Switch labels (null again), some tweaking

[Brian Goetz]

>>
>> At least, if you want a total type, you can make it explicit using
>>   case var x
>> which is always total whatever the type switched upon.
>>
>> So you have two tools to avoid influence at distance in the totality 
>> analysis,
>> - for a switch where you can enumerate all the values enums, sealed 
>> type (boolean should be in that category too IMO, but we did not 
>> agree on that), if you list all the possible cases, a total case is 
>> not required.
>
> Without changes to switch, there is nothing which would break if a 
> "new case" is added (to the enum, or to the sealed hierarchy). So, 
> listing "all possible cases" relies on the assumption that you know 
> what "all cases" are. And right now there's no way to declaratively 
> say: this switch (statement) is gonna cover them all. Brian answer 
> goes a bit in that direction, which is good, for the outermost layer 
> (but the problem still exists somewhat at the nested level).
>

It depends on how much sealing there is.  Suppose we have sealed types 
Container = Box|Bag and Lunch=Soup|Sandwich.  If we are switching on a 
Container<Lunch>:

     switch (lunch) {
         case Box(Soup s):
         case Box(Sandwich s):
         case Bag(Soup s):
         case Bag(Sandwich s):
     }

This switch is exhaustive because:
  - { Soup, Sandwich } is total on on Lunch (with remainder null)
  - therefore { Box(Soup), Box(Sandwich) } is total on Box<Lunch> (with 
remainder null, Box(null) }
  - similarly { Bag(Soup), Bag(Sandwich) } is total on Bag<Lunch> (with 
remainder null, Bag(null) }
  - { Box, Bag } is total on Container (with remainder null)
  - therefore the cases in our switch are exhaustive on Container<Lunch>

If Lunch were not sealed, the compiler would complain, and we'd need 
extra cases to get totality on Box and on Bag, which is needed to get 
totality on Container:

     switch (lunch) {
         case Box(Soup s):
         case Box(Sandwich s):
         case Box(var s):
         case Bag(Soup s):
         case Bag(Sandwich s):
         case Bag(var s):
     }

So I think its similar at every level.  And you can say `var` or `Lunch` 
or `Object`; they're all total in this context.


>> - use "var" so the total case is explicit,  "case var x", "case 
>> Foo(var x)", etc
> Sure - this is a good solution. One minor annoying thing is that we 
> started from a position where we said "var is just for inference" and 
> now we're back in a place where, while  var is still, conceptually at 
> least, about inference, developers will also be using it for totality 
> (as inference guarantees that you are always 100% covered).

No, you can also say `case Object x` or `case Foo(Object x)` and be 
semantically equivalent.  Var is just type inference here; Remi is 
saying "if you don't want to think about what types are total, say var, 
and you'll be right."  But its just inference for "the minimal type that 
is total."