Thanks for all the great feedback so far. The main concern that has been brought up about the introduction of the language feature is the migration of the ecosystem. We agree that this is the most crucial part to make this change succeed without causing massive amounts of churn. Additionally, @hborla brought up great points for introducing an @extensible attribute regardless of the language feature. It helps both with the overall migration story but also with code generation tools.
With all this great feedback in mind, we believe that aligning the language dialects around extensible enums needs to be split up into two separate steps and proposals:
- Allowing extensible enums in non-resilient modules by introducing an
@extensibleand a@preEnumExtensibilityattribute - Aligning the language dialects by creating a new language feature including additional compiler flags and SwiftPM changes to alleviate the migration
We decided to re-focus this proposal on the first step by introducing these two new attributes. With those attributes we are enabling the ecosystem of non-resilient modules to start modeling extensible enumerations. Overall, we still believe that there is a strong desire to align the language dialects and make extensible enums the default since they are the more flexible and safer choice for public APIs.
This brings this proposal very close to what has been previously pitched here and here. However, we think the exploration in this pitch around using a language feature has been very valuable and showed the need for an incremental approach to solving this problem.
You can find the updated version of the proposal in the same evolution pull request.
Excited to hear what everyone thinks about this change of direction!