<div dir="ltr">On Tue, Jan 2, 2018 at 1:27 PM, Goffredo Marocchi <span dir="ltr"><<a href="mailto:panajev@gmail.com" target="_blank">panajev@gmail.com</a>></span> wrote:<br><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"><div dir="auto"><div>Hello all,</div><div><br>On 2 Jan 2018, at 18:36, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><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"><div dir="ltr"><div>I think this whole thing has been unnecessarily convoluted. As a result, the majority of the replies are rabbit holes.</div><div><br></div><div>In my opinion, the true root of the concept in question is as follows:</div><div><br></div><div><b>A list of something is desired:</b></div><div>1 - Pancake</div><div>2 - Waffle</div><div>3 - Juice</div><div><br></div><div><b>Developer wishes to be able to:</b></div><div><b>A)</b> Add new things to the list of choices in the future as they come up with new ideas</div><div><b>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><br></div><div>A and B are <b>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></blockquote><div><br></div><div>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.</div></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>Right, this proposal is about enabling ABI stability and is about libraries that don't ship with the app.</div><div><br></div><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>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. </div><div><br></div><div>The app developer should be informed and have to address the new cases or the removal of old cases.</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>____________________</div><div><br></div><div><b>Part 2:</b></div><div><br></div><div>After this simple desire is clear, there should be two discussions:</div><div><b>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><b>B)</b> How do we approach making this happen behind the scenes?</div><div><br></div><div><b>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>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><br></div><div>_____________________</div><div><br></div><div><b>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><br></div><div>choices Breakfast {</div><div> Pancake, <b>Waffle</b>, Juice</div><div>}</div><div><br></div><div>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><br></div><div>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><br></div><div>_____________________</div><div><br></div><div>Sincerely,</div><div>Jason</div><div><br></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></blockquote></div><br></div></div><span class="">
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></span></blockquote></div><br></div></div>
</div></blockquote><span class=""><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br></div></blockquote></span></div></blockquote></div><br></div></div>