On 20.12.2017 1:58, Ted Kremenek via swift-evolution wrote:
The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through
*January 3, 2018*.
The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
Reviews are an important part of the Swift evolution process. All review feedback should be sent to the swift-evolution
mailing list at:
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review
manager.
When replying, please try to keep the proposal link at the top of the message:
Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
...
Reply text
...
Other replies
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually,
determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
*
What is your evaluation of the proposal?
+0.5.
I'll give additional +0.5 if 'future' case will be included in proposal.
I still do believe that without 'future' case we are introducing now a bug-generator point of code. For me this is
obvious. Especially for the moment when Swift 4 code will be converted to Swift 5 and, as I understand, developer will
see "non-exhaustive enum, add 'default' case" as suggestion during the migration. Instead of "use 'default' or 'future'
", so one can think and decide what needed here.
Having a tool('future' case) to express "switch over non-exhaustive enum exhaustively and let me know if new cases
appear" is IMO a Swifty way, and much better than catching *run-time* bugs when your framework introduced a new enum
value but you were not able to process it *during the compilation*, because you have 'default' case in switch.
Also, probably I missed this and not sure if this even can work, if framework(module) was compiled with Swift4 and
contains 'public enum' - will such enum be treated as exhaustive if framework is imported in Swift 5 code? So, it was
declared without @exchaustive, but for Swift4 exhaustive was the default.
Additionally, I'd like someone answers/comments my question regarding real-world example noted in the proposal
(https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171002/040053.html).
Is it really a very rare use-case for embedded framework&enums, and is it really I have to find a way to use lint-like
tools to check new cases in embedded enum after proposal is implemented? Or use other technique to process all cases of
enum declared in framework?
*
Is the problem being addressed significant enough to warrant a change to
Swift?
Yes, I believe so.
*
Does this proposal fit well with the feel and direction of Swift?
Generally yes, but
* I don't like @exchaustive as attribute, something like "public sealed enum" or "public enum(final)" IMO is more Swifty
syntax
* not safe/dangerous 'default' without able to keep switch exhaustive at
compilation time IMO is not Swift-way
*
If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to
those?
*
Don't know
How much effort did you put into your review? A glance, a quick reading, or
an in-depth study?
Previous discussions, proposal text and proposal review thread
Thanks,
Ted Kremenek
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
