<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">In regards of A, doesn’t this code cover al cases?</div><div class=""><br class=""></div><div class="">@incomplete enum {</div><div class=""> case pancake</div><div class=""> case waffle</div><div class=""> case juice</div><div class="">}</div><div class=""><br class=""></div><div class="">When the @incomplete tag is present, the compiler enforces (with an error) that all switches handle a default case:</div><div class=""><br class=""></div><div class="">switch breakfast {</div><div class=""><div class=""> case .pancake:</div><div class=""> case .waffle:</div><div class=""> case .juice:</div></div><div class=""> default: // <— default case must be present to compile</div><div class=""> break</div><div class="">}</div><div class=""><br class=""></div><div class="">This is also allowed:</div><div class=""><br class=""></div><div class=""><div class="">switch breakfast {</div><div class=""><div class=""> case .pancake:</div><div class=""> // only like pancakes and nothing else!</div><div class=""> default: // <— default case must be present to compile</div></div><div class=""> break</div><div class="">}</div></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thank you,</div><div class="">Eneko</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 2, 2018, at 10:11 AM, Jason Merchant via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">I think this whole thing has been unnecessarily convoluted. As a result, the majority of the replies are rabbit holes.</div><div class=""><br class=""></div><div class="">In my opinion, the true root of the concept in question is as follows:</div><div class=""><br class=""></div><div class=""><b class="">A list of something is desired:</b></div><div class="">1 - Pancake</div><div class="">2 - Waffle</div><div class="">3 - Juice</div><div class=""><br class=""></div><div class=""><b class="">Developer wishes to be able to:</b></div><div class=""><b class="">A)</b> Add new things to the list of choices in the future as they come up with new ideas</div><div class=""><b class="">B)</b> Sometimes select one of the choices to be chosen as the normal choice if no choice is made by the user</div><div class=""><br class=""></div><div class="">A and B are <b class="">separate desires</b>. 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.</div><div class=""><br class=""></div><div class="">____________________</div><div class=""><br class=""></div><div class=""><b class="">Part 2:</b></div><div class=""><br class=""></div><div class="">After this simple desire is clear, there should be two discussions:</div><div class=""><b class="">A)</b> 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)</div><div class=""><b class="">B)</b> How do we approach making this happen behind the scenes?</div><div class=""><br class=""></div><div class=""><b class="">Bonus:</b> 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 <b class="">lack of awareness between the distinctions of what the IDE should do, as opposed to what the syntax of the language should be</b>, and what should be handled behind the scenes by automated tooling.</div><div class=""><br class=""></div><div class="">_____________________</div><div class=""><br class=""></div><div class=""><b class="">My opinion</b>, in answering the above questions is in preference to a simple easy to read and write syntax, something like the following:</div><div class=""><br class=""></div><div class="">choices Breakfast {</div><div class=""> Pancake, <b class="">Waffle</b>, Juice</div><div class="">}</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">_____________________</div><div class=""><br class=""></div><div class="">Sincerely,</div><div class="">Jason</div><div class=""><br class=""></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class=""></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>