> 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.


>> 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

Reply via email to