<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=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 16, 2017, at 11:35, Christopher Kornher 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 class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On Sep 16, 2017, at 11:28 AM, Christopher Kornher 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 class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Sep 16, 2017, at 8:41 AM, Rod Brown 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="auto" class=""><div class=""><br class=""></div><div class="">On 16 Sep 2017, at 7:22 pm, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">I am still unsure why we are choosing again a default that protects library writers more than library users where it is reasonable to expect the former to have better mastery of the language, to architect a library with some scalability, and ability to add unit test to cover themselves from issues than the latter.</div></blockquote><div class=""><br class=""></div><div class="">Because protecting library owners protects library users.</div></div></div></blockquote><div class=""><br class=""></div><div class="">If a library writer can’t remember to declare non-exhaustive enums as such, they probably will forget many more important aspects of creating a library. They probably should not be writing libraries. Arguments like this make sense on the surface, but creating libraries involves hundreds or thousands of decisions. I wish you luck in making that process idiot proof. A library linter could easily warn that exposed enums are exhaustive. The exhaustive keyword should be optional to make the decision obvious and suppress warnings. Complicating the user experience in a vain attempt to make “expert" coding safer is misguided.</div></div></div></blockquote><div class=""><br class=""></div><div class="">This may be a little harsh, but there don’t seem to be many advocates for novice and “ordinary” application developers on this list. That is not unexpected given the number of extremely knowledgeable compiler and library developers on this list (for whom I have the highest respect). I believe that there are more creative (and probably more difficult to build) possible solutions to some of the tough problems in Swift’s future. In that spirit, see below.</div></div></div></blockquote><div><br class=""></div><div>It's definitely good to consider the effects on normal application developers!</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">If you declare it is exhaustive and it was an oversight, and then realise after the fact that you are wrong, you have to open it up. This will break third party apps. It will be disallowed by the ABI compatibility requirements.</div><div class=""><br class=""></div><div class="">If you declare it isn’t exhaustive due to an oversight (or perhaps you’re just not sure yet), and then realise after the fact it is exhaustive, you can close it up. This will not break third party apps. It will also be allowed for ABI compatibility.</div><div class=""><br class=""></div><div class="">This benefits everyone. Make library owners choose a guarantee, rather than be defaulted into it. Much like they have to declare choose to declare “final” on a class: you can’t retroactively reneg that promise: it will break everyone who assumed it to be the case!</div></div></div></blockquote><div class=""><br class=""></div><div class="">It does not benefit the creation of 90+% of enums. It is one more arcane rule for the vast majority of developers.</div></div></div></blockquote><div class=""><br class=""></div><div class="">The Swift compiler could offer a “strict enum exhaustiveness” (bikeshedding not included) switch that could be enabled by default for library targets and disabled by default for “application” targets. The switch would make not explicitly specifying exhaustiveness an error or warning when enabled. Perhaps this could be combined with other options that would tailor the development experience for library/application developers. This would help avoid “zero-sum” choices between benefitting library or application developers in the future.</div><div class=""><br class=""></div><div class="">Xcode and the SPM should be able to distinguish between the target types and generate the proper defaults. I do not believe that this is too mysterious for developers. There would be learning step for developers wiring their first library, but that is not necessarily a bad thing since creating a reusable library requires a different mindset than creating an application.</div></div></div></blockquote><br class=""></div><div>Right now we <i class="">have</i> this notion, but the difference between library and app is signified by "public". My opinion is that between the choices of "multi-module applications have to deal with everything SwiftPM packages do" and "there are different rules for multi-module applications and for SwiftPM packages", the former is preferable just in terms of overall complexity in the language. It's certainly a trade-off! But that's what I'm proposing, and it should be very clear what to do when multi-module app developers encounter the additional rules that come with, well, having multiple modules.</div><div><br class=""></div><div>(We're already likely to have an extra distinction between "libraries built with support for binary compatibility" and "libraries built to be distributed with their clients", but it's still better if that too avoids splitting the language into dialects.)</div><br class=""><div class="">Jordan</div></body></html>