[Pitch] Extensible enums for non-resilient modules

[FranzBusch]

@xwu

Thanks—can you provide specifics on this point? It would be necessary to know how it's expanded on prior proposals and how it's incorporated or explored past feedback in order to evaluate the pitch.

Sure, the proposal at a high level takes a different approach than the previous ones by using a language feature to stage in the alignment of behavior between the dialects. It is similar to the previous ones by using attributes to explicitly control the extensibility of enumerations. However, the attribute to mark an enumeration as extensible is only provided as a migration tool with the expectation that once the new language mode arrives the attribute is no longer needed in modules adopting the language mode.

@xwu

This addition is ill-considered: it breaks your own stated goal to "align the behavior" between language dialects and instead now adds further differences.

I also do not understand why there are now two attributes that do the same thing. What would be the semantic difference between @frozen and @nonExhaustive for a non-resilient library that necessitates a distinct attribute and new errors?

That's a fair critic and I have been going back and forth on it. In previous pitch threads, it was raised that @frozen implies more than just extensibility on enums and using the attribute in non-resilient modules could lead to confusion. I personally agree with this and I think we are better off having a new set of attributes decoupled from the concept of frozen.

However, you are right that the goal is to align both modes. So as far as I can see we have two options:

1. Re-use @frozen to mark enums as non-extensible in non-resilient modes and introduce a @nonFrozen to provide a migration path
2. Re-use @frozen to mark enums as non-extensible in non-resilient modes and expect that the migration path is to enable the language feature and mark all existing public enums as @frozen
3. Introduce a new set of attributes. This leaves the open question if it is possible to have a @nonExtensible non-frozen public enum in a resilient module otherwise we have divergent behavior again.

Now after having spelled all of this out. I think the most sensible choice is actually 2. It only requires a new language feature. Re-uses the existing attribute that works in both dialects. While still providing a migration path.