[swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Vladimir.S]

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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>