<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="">-1</div><div class=""><br class=""></div>It took awhile to catch up. I understand the motivation but don't agree with the solution. The suggested proposal adds language complexity that can hopefully be solved in other ways.<div class=""><br class=""></div><div class="">In catching up I related to Howard Lovatt's response. Jordan responded:<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 2:33 PM, Jordan Rose 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 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=""><div class="">I find it interesting that you call this the "unsafe" case. <a href="https://imgur.com/4OWRavD" class="">From my point of view</a>, it is very much in line with Swift's current design to have the default be "force clients to consider all possibilities" (like Optional), as well as "let library authors decide what a client should be able to rely on" (like 'open').</div></div></div></blockquote><div><br class=""></div><div>I don't understand this. Optional is exhaustive. What you're describing is more like Swift error handling, which is quite different and much more cumbersome in use.</div><br class=""><blockquote type="cite" 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=""><div class="">This is an interesting point that I probably should have expanded more in the "comparison with other languages" section. Swift has protocols too, and you can build most of the features of enums with protocols. (Set aside the inferior pattern-matching for now; that's something we could add to Swift.) This is currently much more heavyweight than enums, but let's roll with it.</div><div class=""><br class=""></div><div class="">Next we have to deal with C enums, which can have "private cases" or newly-added cases. Okay, maybe those get imported as structs instead, like NS_OPTIONS. That's not too bad, is it?</div><div class=""><br class=""></div><div class="">Now we're back in a place where 'enum' always means "exhaustive". That's good, right? Except…now we have a kind of type where the recommendation will be "don't use these in your library's public API; they'll be stuck that way forever", a trap waiting for library authors. That's a problem C has with structs, and it's something we don't want to bring into Swift. Making a library necessarily requires more care than making an app, but we don't want there to be techniques that<span class="Apple-converted-space"> </span><i class="">only</i> make sense within a module, and are<span class="Apple-converted-space"> </span><i class="">discouraged</i> when writing a library.</div><div class=""><br class=""></div><div class="">So we can implement this world in Swift. I just don't think it'll be a better one. When someone makes a library, the default should be safe<span class="Apple-converted-space"> </span><i class="">for them.</i> That means that they reserve the ability to add cases, and<span class="Apple-converted-space"> </span><i class="">also</i> to make the enum "exhaustive" in the future if it turns out that's the right thing to do.</div><div class=""><br class=""></div><div class="">(You're free to continue to disagree with me on this; thanks for getting me to write it out.)</div></div></blockquote></div><div><br class=""></div><div>I don't think the default third-party library case mirrors Foundation and UIKit (and authors that provide libraries like that must take more care in general and don't require extra language sugar that benefits just them). There are plenty of library authors whose default case is: when you upgrade to use our latest version, you need to consider all added cases, as it's source-breaking. I think this is far more common than the well-kempt releases Apple shepherds through each year.</div><div><br class=""></div><div>I don't think we should lose our primitive type that always requires exhaustive switching, and I don't see the need to overcomplicate the language when we already have at-hand solutions (like extensible structs). If we're worried about library authors falling into the trap of misusing enums, we should provide a better mechanism for declaring raw-representable (or similar) entities, via something like NS_RAW_REPRESENTABLE, compiler magic, and/or a hygienic macro system.</div><div><br class=""></div><div>I'd also like to point out that the current state of Swift development requires frameworks separate from the app:</div><div><br class=""></div><div>1. If you want to import code into a playground. Playgrounds are a celebrated form of code demonstration, but app executable code cannot run in a playground. It needs to be extracted to a framework first.</div><div><br class=""></div><div>2. SPM executables cannot run tests or have test targets. Testable SPM code needs to be extracted to a framework. If you want to test your code, it needs to be in a framework.</div><div><br class=""></div><div>Both cases above affect app developers that aren't necessarily in the library biz. It's not great if the default for them is enums that suddenly become non-exhaustive.</div><div><br class=""></div><div>Stephen</div></div><div><br class=""></div></body></html>