[Pitch] Extensible enums for non-resilient modules

I think, definitionally, there has to be a point along the migration path where these are mutually incompatible goals, unless every public enum has to be annotated in some way (which I would consider actively undesirable). I think that's what your first paragraph is saying also, if I understand you correctly.

Adding even a single case to a single enum is a source-breaking change for clients of a non-resilient library in the current state of things, but adding any number of cases to any number of extensible enums ceases to be source-breaking with the full-fledged feature you pitch.

Therefore, for any non-resilient library that will ever add any case to any enum, turning on this full-fledged feature in one go is the least source-breaking migration path possible for users. This leaves only non-resilient libraries that will never add any case to any enum: they can turn on the full-fledged feature and annotate all of their enums as @frozen and not break any clients' source.

What am I missing?

1 Like