Expression switch exception naming

[Brian Goetz]

> I think I do finally understand, thanks to your example, what is different between this and the previous kinds of incompatible changes. The JDK (and some libraries) makes strong promises not to break compatibility. Yet we simply can't throw up our hands and refuse to add constants to enums like ElementType. So either we need a way to mark it unsealed, or we have to do some very fiddly messaging, like "well, it's binary-compatible, and it's also source-compatible except for any breakages you opted into via defaultless switch expressions." The trouble with that being that many developers won't have actually consciously opted into it at all. But maybe that is a viable option?

Right.  I think there are two kinds of enums, call them sealed and unsealed, in their promises about how expected or unexpected new constants will be.  You’re right that either default — sealed or unsealed — has problems; if the default is sealed, then anyone who has written an intended-to-be-extended enum now has to go and mark it, and if the default is unsealed, their clients will be irritated.  And worse, many maintainers will be wrong about their intent to add new enum constants in the future.  Very few enums are as black-and-white as the extremes of `enum BOOL { TRUE, FALSE }` and `ElementType`.  

But I think there _are_ two cases, and its reasonable the language to look to a declaration-site cue as to whether to assume sealed-ness or not. (I might think differently tomorrow.)  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180419/09a6ff2a/attachment.html>