[Proposal] Non-exhaustive enums #751
Conversation
|
Exhaustive enums is one of my favorite features of Swift and I don't think it would be a good idea to allow anything but that. From the proposal introduction:
Adding a case should be a source-breaking change IMO since it forces consumers to consider the new behavior. If
I don't agree with this definition. Exhaustive means that at the time of me writing some code, there are no additional cases to check (ie a finite number of cases). This has nothing to do with the number of cases growing in the future, via an update to the library/API. |
- Default to 'nonexhaustive' in Swift 5 mode, instead of having no default. - Mention Brent Royal-Gordon's '#invalid' idea. - Clean up typography.
- Add a source example of an unannotated public enum, to make it clear that this is legal. - Treat enums as exhaustive when they come from testably-imported modules. - Don't start warning on missing default cases for C enums in Swift 4 mode until Swift 5 is actually released. We shouldn't even introduce warnings for this in a minor version release unless someone specifically asks for the enum to be non-exhaustive.
- Add a "Comparison with other languages" section. - Clarify up front that this only affects cross-module public enums. - Mention the possibility of a compatibility checker. - Link to Rex Fenley's counter-argument in favor of exhaustive-by-default. - Include a code example for why `#invalid` isn't sufficient for testing default cases. - Include "sealed"/"nonsealed" as a possible spelling (cf. Scala). - Acknowledge "Drop `nonexhaustive`" as a considered alternative. - Remove references to a "C++ proposal" for a "non-exhaustive" annotation. This one paper from last year hasn't gone anywhere yet. - Link to the implementation PR.
Vladimir and others have been persistent in bringing this up, and it deserves a mention in the proposal itself, just like Rex's points about the default behavior.
This would make adding or removing a raw type an ABI-breaking change, and since it's possible to do this without breaking source that deserves its own discussion.
jrose-apple
force-pushed
the
non-exhaustive-enums
branch
from
27825f1 to
5f8eed5
Compare
Per preliminary discussions in the core team.
We may need this temporarily to implement the overlays, but we don't really want to make the language more complicated in this way. The only +/- attribute pair we have today is @objc/@nonobjc, and that one's actually meaningful. Also, discourage the "member" approach even more. The core team is also not in favor, so there's not much point in that being discussed during the formal review period.
As discussed in Enums and Source Compatibility, with additional orphaned thread. Initial implementation at swiftlang/swift#11961. Thanks to everyone who gave pre-review feedback!