> On Dec 20, 2017, at 1:36 PM, Jordan Rose <jordan_r...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
