[swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums
colin at springsandstruts.com
Wed Dec 20 12:13:14 CST 2017
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” or Standard ML’s exceptions (which are "open” in this way by default)
Thanks for everyone's hard work, particularly the authors,
: https://realworldocaml.org/v1/en/html/variants.html#polymorphic-variants <https://realworldocaml.org/v1/en/html/variants.html#polymorphic-variants>
: 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?
> Ted Kremenek
> Review Manager
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution