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

Thu Dec 21 13:55:11 CST 2017

Okay, thanks Jordan. I appreciate your perspective, and I admit that the proposal is technically compelling. My criticism was from a place of respect and admiration, and while I may have missed the deeper technical points of the proposal, I’ll still caution about how this change will be received by the Swift developer community. Proposals like this one could benefit from a plain-language explanation that this (as Joe Groff explained on twitter) fixes a bug. Maybe even a few more before and after examples? That would help the proposal get ahead of any negative reaction.

Ash

-- 
Ash Furrow
https://ashfurrow.com/

On December 21, 2017 at 1:55:40 PM, Jordan Rose (jordan_rose at apple.com) wrote:

Thanks for your response, Ash. Comments inline.

On Dec 20, 2017, at 11:49, Ash Furrow via swift-evolution <swift-evolution at swift.org> wrote:

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md

What is your evaluation of the proposal?

-1.

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

I’m afraid not.

From my perspective as a Swift user, this change represents nontrivial language churn without providing a solution to a problem I have. The proposal doesn’t describe any benefits to me as an open source library maintainer or as a Swift developer. With earnest respect, the motivation section reads like “enums grow sometimes, but we like to exhaustively switch over them, so wouldn’t it be cool if …”, which is only a theoretical motivation. It fails to describe how and why this proposal would improve my Swift code or my experience using Swift.

This appears to be a solution to a non-existing problem. I worry that making this change will alienate developers from Swift and I caution against accepting it.

I wish it were, but unfortunately it's a very real problem. Cases are added to Cocoa all the time, and currently it is undefined behavior if one of those cases makes it into a switch defined in Swift. ("undefined behavior" = "no guarantees of memory safety, type safety, or even which functions are going to get invoked in the rest of the function") This is a terrible state of affairs that we need to do something about, and "make it a deterministic trap" isn't a good enough answer.

We also already know that we have clients that want to add new cases to Swift enums without breaking source or binary compatibility: the Apple overlays. It's true that this is more of a "theoretical motivation" for source framework authors at this time.

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

It may have at one time point in time, but not now.

The chaotic churn of the language, the syntax, and the standard library is supposed to be behind us. We need to accept that things fell into place as they did, often in imperfect ways. We probably could correct all the imperfections, but when would we ever stop? Language churn has a cost. This proposal is something that I could definitely see being a part of Swift 2 or Swift 3, but we have already decided that enums are exhaustive. This change, and changes fundamental to the cognitive model Swift programmers already have of their tool, need to be heavily weighted against language churn

There's a difference between imperfections that mean something is a bit harder to use, or not named the right thing, and imperfections that lead to crashes or core capabilities not being expressible. Being able to add cases to enums is something Cocoa developers have relied on for years in Objective-C, and so it isn't really sensible to not have this feature in Swift. I definitely wish we could have gotten to it sooner.

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

Scala’s match syntax bears a striking resemblance to Swift’s switch syntax; however, Scala does not require exhaustive cases. If the developer does not include a default case and none of the cases match the expression, an exception is thrown. Because of Swift’s error-handling model, I don’t know that this behaviour would be desirable either (though I will say it makes sense in Scala).

This is certainly an option; it's in the proposal under "Alternatives considered" as 'switch!' (causing a deterministic trap rather than an exception). That doesn't seem sufficient to deal with the realities of Cocoa, though.

Jordan

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

I read most of the proposal (okay I skimmed some of the nitty-gritty, but I read to the end of “Source compatibility”) as well as looked over the pre-review threads and skimmed GitHub pull request thread.

-- 
Ash Furrow
https://ashfurrow.com/

On December 19, 2017 at 5:58:14 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
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?

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
_______________________________________________
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/20171221/ac6218ce/attachment-0001.html>