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

[Colin Barrett]

> On Dec 20, 2017, at 1:36 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> Thanks for the links, Colin. I think neither of these approaches are appropriate for Swift, largely for the same reason: they can't be used to define a library's API. Polymorphic variants are ad-hoc union types (much like tuples are ad-hoc structs) which—apart from having other problems in Swift previously discussed on this list—means that you can't add new cases to them. That is, any API which takes `(red(r: Int) | green(g: Int) | blue(b: Int))` today can't add `alpha(a: Int)` in the future, because that would change the type.
 
It would change the type yes, but not in a binary incompatible way. Imagine this for the OS version, using OCaml pseudocode

type VERS = [> `10_0 | `10_1 | … | `10_13 ]

Then, next year, you’d change VERS to be,

type VERS = [> `10_0 | `10_1 | … | `10_13 | `10_14 ]

Any code that dealt with a VERS would still work, as it had to handle that it could contain other tags.

> ML-style exceptions have the opposite problem; they are completely unconstrained and so a client can add new "cases" without the library author being prepared. (Swift's error-handling model in general behaves a lot like this, except it doesn't get ML's knowledge of which errors might be thrown.)

Yes, I was imagining that this would be for something with an OCaml type like [> ]  or TOP, which I don’t believe is a thing? My OCaml-fu is quite weak.

> I'd sum this up by saying Swift is differing from ML and from most other languages because it is solving a different problem. Swift is designed such that the compiler does not require whole-program knowledge to produce a correct, working, type-safe program. It will use any cross-module knowledge it can for optimization purposes, but the language semantics do not depend on it. And this is critical, as you note, for libraries with binary compatibility concerns.

That is… not different from ML? ML’s modules have precisely this properly, do they not? Or am I misunderstanding what you’re saying here.

> Jordan

Thanks for the reply, it’s appreciated! Hope you’re well in California, envious of your weather trudging thru the snow here in NYC.

-Colin

> 
> 
>> On Dec 20, 2017, at 10:13, Colin Barrett via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 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 <mailto: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 <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/e2223635/attachment.html>