[Pitch] Non-Frozen Enumerations

[Karl]

@Jumhyn

One minor gripe I have is that I would prefer that the 'frozen' terminology remain relegated purely to library evolution mode, and that we use something like @nonExhaustive here if we want to go with an attribute on the type definition.

I actually think that "library evolution mode" is the thing that's poorly-named -- all libraries need to care about evolution, and the 'frozen' terminology, meaning "can this thing evolve or not?", is useful to all of them.

There are some other benefits:

1. There are libraries which can be used either as source packages or binaries. swift-system is one example, but it also applies to user libraries that may sometimes be used as xcframeworks.

   If these libraries annotate all enums which can't evolve with @frozen, and those that can with @nonfrozen, the source and binary distributions would behave exactly the same for clients.

2. There is symmetry with partial consumption of non-copyable types in non-resilient libraries:

   @Michael_Gottesman

   This suggests that we may want to add the ability for a library author
   to explicitly notate such public types that they are giving up these source
   compatibility properties. A natural way to do this is to endow @frozen with
   this meaning when applied to public noncopyable types in libraries without
   library evolution enabled. As an additional benefit, by extending the meaning of
   frozen in this manner, we prevent an additional difference in between Swift when
   compiled with/without library evolution enabled: in both language modes, public
   noncopyable types can only be partially consumed outside of their current module
   if they have @frozen attached.

   In that proposal, a @frozen struct promises that it will not gain stored members, allowing clients to totally de-structure the struct without fear of source incompatibility as the library evolves.

   It's very similar to what we're talking about here - where even without library-evolution mode enabled, @frozen means that clients may totally destructure the enum because it will not evolve new cases.

   That said, I see you also mentioned in response to that proposal that you weren't happy with @frozen being used in that way (so +10 for consistency). I guess I'd lean more towards Michael and Xiaodi's interpretation in that thread that it's valuable to have less divergence. I like the symmetry between frozen and non-frozen, but if there's consensus on something different of course I'd be happy to adopt that.