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