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

Howard Lovatt howard.lovatt at gmail.com
Tue Dec 19 22:15:04 CST 2017


As an aside: there seems to be increasingly comments about proposals that say:

  1. This was discussed at the evaluation stage and rejected. 
  2. This is how it is implemented in the patch.

And other comments along those lines. Neither the pre-proposal discussions nor the proposed implementation are intended to limit the scope of the review. Therefore I don’t think people should raise this as reasons. You should remember that the process is deliberately staged this way and different people may well be commenting (in fact the process rather assumes that people in the formal review will be a wider set of people). 

Anyway gripe over. 

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
What is your evaluation of the proposal?

+1/2

I only give this a half because whilst it is important I can see three issues:

  1. It doesn’t seem very Swift like to have a different rule, default non-exhaustive, for public as opposed to non-public. 

  2. It doesn’t seem very Swift like to have the default the unsafe case. 

  3. Other languages have better solutions - see below under other languages

Is the problem being addressed significant enough to warrant a change to Swift?

Yes, Swift ABI compatibility going forwards is important

Does this proposal fit well with the feel and direction of Swift?

No. As mentioned above different rules for public and a non-safe default don’t see that Swift like. 

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Both Java and Scala have a better solution. In these languages enums (Scala calls them case classes) can implement protocols and the user of an enum rarely writes a switch statement, instead they call protocol methods. Enums in these languages are a fixed set of derived classes; i.e. normal OO programming rather than functional programming, which works well in the case of wanting to expand later the number of enum cases. 

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Have followed the discussions. Used enums in Swift and other languages extensively. 

-- Howard.

> On 19 Dec 2017, at 12:58 pm, Ted Kremenek <kremenek at apple.com> wrote:
> 
> 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?
> 
> 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?
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/86a75ed9/attachment.html>


More information about the swift-evolution mailing list