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

[Eneko Alonso]

In regards of A, doesn’t this code cover al cases?

@incomplete enum {
  case pancake
  case waffle
  case juice
}

When the @incomplete tag is present, the compiler enforces (with an error) that all switches handle a default case:

switch breakfast {
  case .pancake:
  case .waffle:
  case .juice:
  default:      // <— default case must be present to compile
    break
}

This is also allowed:

switch breakfast {
  case .pancake:
    // only like pancakes and nothing else!
  default:      // <— default case must be present to compile
    break
}

I think it is safe for the compiler not to warn users when new cases are introduced (by the new OS, for instance), in similar way as users are not warned when new methods are added to a class, or new classes added to a framework. For instance, if a new case is added for UILabel text alignment, I don’t _really_ need to know unless I wanted my app to support that case. Users would be able to get that information from the documentation.

In regards of B (select one of the choices to be chosen as the normal choice if no choice is made by the user), sounds like an edge case and should be left for a separate proposal.


Thank you,
Eneko


> On Jan 2, 2018, at 10:11 AM, 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.
> 
> ____________________
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180102/cd43cb6a/attachment.html>