> On Apr 19, 2018, at 6:27 PM, Brian Goetz <brian.go...@oracle.com> wrote:
>
>> 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.)
What I found in reviewing enums in the JDK is that it's pretty hard to find
enums you can _guarantee_ will never grow. java.time.Month, sure. But what
about Thread.State? StandardOpenOption? System.Logger.Level? Am I prepared to
guarantee that we'll never have a reason to add another case?
So some sort of declaration-site feature would, I fear, either get little use
or be routinely ignored when changes must be made.
—Dan
