Opting into totality

[Brian Goetz]

> 
>> Which leaves:
>> 
>>   { statement, expression } x { arrow, colon } x { switch, total-switch }
>> 
>> where an expression switch of any stripe is automatically upgraded to a total-switch of that type.
> 
> This description actually does not quite describe the current behavior: for an expression switch, if the type of the selector expression is enum, then the switch is _assumed_ to be total (the user need not supply a “default” label), but if the type is int or String, then the switch is _required_ to be total (the user must supply a default label).  Did you mean to suggest a change from this current behavior, so that the user would not need to supply a default label for the int and String versions? (My guess is “no”.)


What I meant to suggest is that a switch is total if either (a) it says “total” or (b) it is an expression switch.  A total switch must either have a default clause or have an optimistically total set of cases, otherwise a compilation error ensues.  Total switches get some extra implicit cases to handle any residue.  

In the current language, the only optimistically total set of cases is an enum switch where all the constants are covered, but as we add sealed types and deconstruction patterns, there will be more ways to get there.  

If we plan to complete the set of primitive types that can be switched on, we’d treat `boolean` as if it were an enum with constants `true` and `false`.  (We could conceivably do the same for byte, short, and theoretically even int (though I suspect we’d hit file system length limits), but I think this would be silly.)  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200825/cedf0db6/attachment.htm>