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

[Colin Barrett]

I very much agree with the motivations for this proposal. It identifies a clear, urgent need.

I disagree that the proposed solution is a good solution. It makes a very significant, and confusing, change to the language that does not have much precedent in other languages. This goes against the stated design guidelines for the Swift language.

I would much rather see Swift follow the lead of other ML languages and introduce something like “polymorphic variants”[1] or Standard ML’s exceptions (which are "open” in this way by default)

Thanks for everyone's hard work, particularly the authors,
-Colin

[1]: https://realworldocaml.org/v1/en/html/variants.html#polymorphic-variants <https://realworldocaml.org/v1/en/html/variants.html#polymorphic-variants>
[2]: https://www.cs.cmu.edu/~rwh/introsml/core/exceptions.htm <https://www.cs.cmu.edu/~rwh/introsml/core/exceptions.htm> 

> On Dec 19, 2017, at 5:58 PM, Ted Kremenek via swift-evolution <swift-evolution at swift.org> 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 <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 <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 <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?
> 
> Is the problem being addressed significant enough to warrant a change to Swift?
> 
> Does this proposal fit well with the feel and direction of Swift?
> 
> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> Thanks,
> Ted Kremenek
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/ff2d3d6a/attachment.html>