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

[Jordan Rose]

> On Dec 19, 2017, at 20:15, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md>
> What is your evaluation of the proposal <x-apple-data-detectors://7>?
> 
> +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. 
> 
I guess people are still misunderstanding this. Within a module, switches must still be exhaustive, always, because the switch can never get out of sync with the enum definition. The "exhaustive" annotation only applies to clients across module boundaries.


>   2. It doesn’t seem very Swift like to have the default the unsafe case. 
> 
I find it interesting that you call this the "unsafe" case. From my point of view <https://imgur.com/4OWRavD>, it is very much in line with Swift's current design to have the default be "force clients to consider all possibilities" (like Optional), as well as "let library authors decide what a client should be able to rely on" (like 'open').


>   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. 
> 
This is an interesting point that I probably should have expanded more in the "comparison with other languages" section. Swift has protocols too, and you can build most of the features of enums with protocols. (Set aside the inferior pattern-matching for now; that's something we could add to Swift.) This is currently much more heavyweight than enums, but let's roll with it.

Next we have to deal with C enums, which can have "private cases" or newly-added cases. Okay, maybe those get imported as structs instead, like NS_OPTIONS. That's not too bad, is it?

Now we're back in a place where 'enum' always means "exhaustive". That's good, right? Except…now we have a kind of type where the recommendation will be "don't use these in your library's public API; they'll be stuck that way forever", a trap waiting for library authors. That's a problem C has with structs, and it's something we don't want to bring into Swift. Making a library necessarily requires more care than making an app, but we don't want there to be techniques that only make sense within a module, and are discouraged when writing a library.

So we can implement this world in Swift. I just don't think it'll be a better one. When someone makes a library, the default should be safe for them. That means that they reserve the ability to add cases, and also to make the enum "exhaustive" in the future if it turns out that's the right thing to do.

(You're free to continue to disagree with me on this; thanks for getting me to write it out.)

Jordan


> 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 <mailto: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 <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?
>> 
>> 
> _______________________________________________
> 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/ff77d25a/attachment.html>