[Pitch] Extensible enums for non-resilient modules

[FranzBusch]

@tshortli

I agree in principle that the effect of turning this feature on is the same as exercising a right that was already afforded to library authors. That said, we don't have precedent (that I am aware of) where turning on a Swift language feature implies a source break for clients all on its own. If we settle on the conclusion that adopting ExtensibleEnums in a module is inherently a semver breaking change when that module already vends non-frozen enums, then I have no problem with that. I do think it creates a novel problem for the ecosystem regarding adoption of language features, though. And if we decide we need a way to mitigate the problem, then I'd like to see something like @preEnumExtensibility provided rather than encouraging library owners to use @frozen inappropriately (which I thought I had seen suggested elsewhere in the discussion but I could have misinterpreted).

I don't see a way around enabling ExtensibleEnums not resulting in a SemVer major without the library authors going around and marking all existing public enumerations as non-extensible (regardless of what we call the attribute). All public enums in the ecosystem must be treated as non-extensible.

I thought about introducing a similar attribute to @preconcurrency like you suggested as well but I fail to see how it would work in practice. Let's imagine module A turns on the new language feature and marks all existing public enumerations with the hypothetical @preEnumExtensibility annotation. So far I could only think of two effects that annotation could have on consuming modules:

1. Downgrade the error of requiring an @unknown default to a warning
2. Synthesize at compile time a @unknown default. I think the only valid thing to do in the synthesized code is to fatalError though.

Let's say we pick either of the two options. Now the new minor version of the library is released and all consuming modules continue to compile potentially producing new warnings. A few releases later the authors of module A want to add a new case now to one of the previously marked @preEnumExtensibility enumerations. What would happen now in the consuming modules? If we went with option 1. this will now produce an error that we are no longer exhaustively switching. I don't see a way that we can downgrade that error. If we went with option 2. the code would continue to compile, the consuming module would get a new warning of the missing case. However, it would now open up a real possibility to hit the fatalError. @tshortli do you see any other option how we could handle @preEnumExtensibility in consuming modules that also works when new cases are added?

I also briefly want to take a step back and talk about the goals we want to achieve here:

1. Align the differences between the two language dialects in a future language mode
2. Provide developers a path to opt-in to the new behavior before the new language mode so they can start declaring new extensible enumerations
3. Provide a migration path to the new behavior without forcing new SemVer majors

The following is a nice-to-have but not required:

1. Enable existing enums in packages to be extended without a new major

If we can solve the nice-to-have creatively I would be delighted but in my opinion it isn't a requirement to achieve the overall goals. As a package author myself, I'm happy to accept that existing public enumerations are non-extensible until I decide to mint a new major. Importantly, I want to be able to declare new extensible enumerations before that new major though.