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

[Goffredo Marocchi]

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.

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/c3613bed/attachment.html>