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

Xiaodi Wu xiaodi.wu at gmail.com
Tue Jan 2 13:41:19 CST 2018

On Tue, Jan 2, 2018 at 1:27 PM, Goffredo Marocchi <panajev at gmail.com> wrote:

> Hello all,
> On 2 Jan 2018, at 18:36, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution <
> swift-evolution at swift.org> wrote:
>> I think this whole thing has been unnecessarily convoluted. As a result,
>> the majority of the replies are rabbit holes.
>> In my opinion, the true root of the concept in question is as follows:
>> *A list of something is desired:*
>> 1 - Pancake
>> 2 - Waffle
>> 3 - Juice
>> *Developer wishes to be able to:*
>> *A)* Add new things to the list of choices in the future as they come up
>> with new ideas
>> *B)* Sometimes select one of the choices to be chosen as the normal
>> choice if no choice is made by the user
>> A and B are *separate desires*. In some circumstances a developer may
>> want to add a new choice and make it the normal choice when there was no
>> normal choice was clarified before.
> I don't think this is an accurate summary of the problem being tackled
> here. Rather, we are how to enable the vendor of a nonexhaustive enum to
> add new cases without breaking binaries compiled against previous versions.
> There is little here to do with what a "default" should be. Indeed, it is
> an explicit design decision of Swift not to support types having an
> implicit default value.
> There is no way a library developer of libraries bundled in the app can
> break the app by adding new cases. They may cause compiler issues when the
> app author tries to update the library, but it will not break existing apps.
> The concern for updating enums is mostly an Apple / OS related concern for
> libraries/dynamic frameworks the app does not ship with, but links to at
> runtime and we should have an exception for that. We should not use the
> same solution for both and lose exhaustiveness checks when we do not need
> to. It would be wrong.

Right, this proposal is about enabling ABI stability and is about libraries
that don't ship with the app.

However, I disagree strongly with your point above. There should not be
dialects of Swift depending on how you link a framework. The point made
above is salient that there are, semantically, certain enums that are
exhaustive (for example, Optional, which can only have two cases), and
others that are nonexhaustive (for example, a list of foods, which will
never be complete).

Those dynamic frameworks should be the one that have to opt-in (even better
> if it is done automatically for them) in non-exhaustive extra resilient
> behaviour, not libraries you ship in the app.
> The app developer should be informed and have to address the new cases or
> the removal of old cases.
>> ____________________
>> *Part 2:*
>> After this simple desire is clear, there should be two discussions:
>> *A)* In a text only coding language, what would we like the syntax to
>> look like? (Without regard to past-bias. What should it really be, forget
>> what mistaken design choices were made in Swift in the past)
>> *B)* How do we approach making this happen behind the scenes?
>> *Bonus:* Given that some of us have changed our approach to programming
>> significantly beyond text based coding, and into more dynamic mediums of
>> programming in other niches, and even here and there in Xcode - I would
>> recommend considering how the IDE would show a modern version of this
>> concept. I feel too often that Swift design syntax has a *lack of
>> awareness between the distinctions of what the IDE should do, as opposed to
>> what the syntax of the language should be*, and what should be handled
>> behind the scenes by automated tooling.
>> _____________________
>> *My opinion*, in answering the above questions is in preference to a
>> simple easy to read and write syntax, something like the following:
>> choices Breakfast {
>>     Pancake, *Waffle*, Juice
>> }
>> If a "default" choice is desired, it is obvious to me that I would select
>> the choice from the IDE, and it would be visually indicated that it was the
>> default.
>> When changes occur, whether new choices are added, old ones are removed
>> or changed, or a default is added, changed, or removed - a behind the
>> scenes automated tool analyzes the changes and presents migration options
>> through the IDE.
>> _____________________
>> Sincerely,
>> Jason
>> _______________________________________________
>> 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/20180102/fc46e643/attachment.html>

More information about the swift-evolution mailing list