<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Since I was just looking at the Default section, it wasn’t clear that the default was just for the external case. But mostly I just wasn’t paying close attention. Also, it’s not entirely clear whether nonexhaustive enums can be used within the same module, but again, I may just be missing something.<div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jon</div><div class=""><br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Sep 18, 2017, at 1:09 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">That is in fact what the proposal states:<div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Currently, adding a new case to an enum is a source-breaking change, which is very inconvenient for library authors. This proposal aims to distinguish between enums that are <i class="">exhaustive</i> (meaning they will never get any new cases) and those that are <i class="">non-exhaustive,</i> and to ensure that clients handle any future cases when dealing with the latter. This change only affects clients from outside the original module.<br class=""></blockquote><div class=""><br class=""></div><blockquote type="cite" class="">When a client tries to switch over a <font face="Menlo" class="">nonexhaustive</font> enum, they must include a <font face="Menlo" class="">default</font> case unless the enum is declared in the same module as the switch.<br class=""></blockquote><div class=""><br class=""></div><div class="">Do you have any suggestions on how to make this clearer in the proposal?</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 15, 2017, at 21:40, Jon Shier <<a href="mailto:jon@jonshier.com" class="">jon@jonshier.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>In that case Jordan, can Swift not treat it like open? i.e. Internally to a module, unmarked enums are still exhaustive by default, but when made public and used beyond the module, it becomes non-exhaustive? I think this has been discussed before and perhaps discarded as confusing, but it doesn’t seem to be any more confusing than open being the default internally and closed the default publicly. Otherwise you’re essentially forcing what is likely the vast majority of enum usage to adopt a bit of boilerplate that will only be used by the vast minority of libraries (almost entirely libraries shipped by Apple). <div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jon<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 15, 2017, at 8:07 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=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi, Rex. I definitely agree that 'exhaustive' is the right model for a multi-module app; indeed, there's no real reason for a single project to do anything else. However, it is not always the right behavior for libraries that actually get distributed, whether as source or as binary. In this case we want to minimize the error of omission: in the app case, forgetting "exhaustive" is an annoyance that you notice and fix once across your code base, but in the library case forgetting the "default case" means putting out a source-breaking release, and for libraries that have binary compatibility constraints there's no recourse at all.<div class=""><br class=""></div><div class="">While most of the proposal deals with the experience we've had with the Apple SDKs (as written in Objective-C), we actually <i class="">have</i> run into this case in Swift already. The Swift Playgrounds app comes with a framework, PlaygroundSupport, that can be used from within a playground. It's important that when they upgrade the app, existing playgrounds don't break, since the end user may not have access to the entire code of the playground. (Remember that playgrounds are often authored by one developer or group, but then run and modified by someone else with a much lower skill level!) <i class="">That</i> means that PlaygroundSupport can't currently vend any enums that they expect playground authors to exhaustively switch over.</div><div class=""><br class=""></div><div class="">(And to make it even more specific—and appealing—one of the enums they were considering would be a representation of the Swift AST. This can obviously change from release to release, but previous switch statements should stay valid.)</div><div class=""><br class=""></div><div class="">Now, this is an example we know about, so we could certainly make it explicitly non-exhaustive. But in general we're in the same situation as 'open': if we want to be friendly to library authors, we need to make the default thing be the one that promises less, even if it means a bit of extra work in the "I-actually-own-everything" case.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Jordan</div><div class=""><div class=""><br class=""></div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 15, 2017, at 15:47, Rex Fenley <<a href="mailto:rex@remind101.com" class="">rex@remind101.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hey Jordan,<div class=""><br class=""></div><div class="">Thank you for the time writing this up. I've been following along to the discussion somewhat closely and have kept silent because `exhaustive` was originally set to be the default for enums. However, that changed and so I'd like to voice my opinion, I frankly don't like this idea.</div><div class=""><br class=""></div><div class="">At remind we use algebraic data types religiously for managing state and data and rely on exhaustive pattern matching to guarantee we're handling all states in our code. We're splitting out our code across modules and having this guarantee has been a joy to work with.</div><div class=""><br class=""></div><div class="">The benefit of making nonexhaustive the default for Swift 5 across all multi-module code (besides C code) seems minimal to me. If a developer feels like they're unnecessarily managing enum cases, they can simply add a `default` case whenever they please. This is already the case and I'm curious if there's every been any complaints about this and what they would be. I'd prefer to be cautious and force exhaustive pattern matching in all possible cases and leave it up to the developer to choose not to.</div><div class=""><br class=""></div><div class="">Ideally in my mind, these keywords won't be necessary. All Swift enums will remain as they are, exhaustively pattern matched by default. Enums from C code will be explicitly nonexhaustive in all cases.<br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><span class=""><div style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" class=""><span style="font-size:16px;font-family:Arial;background-color:transparent;font-style:italic;vertical-align:baseline;white-space:pre-wrap" class="">Rex Fenley</span><span style="font-size:16px;font-family:Arial;background-color:transparent;vertical-align:baseline;white-space:pre-wrap" class=""> </span><span style="font-size:11px;font-family:Arial;color:rgb(153,153,153);background-color:transparent;vertical-align:baseline;white-space:pre-wrap" class="">|</span><span style="line-height:1.15;font-family:Arial;color:rgb(153,153,153);background-color:transparent;vertical-align:baseline;white-space:pre-wrap" class=""> </span><span style="font-size:11px;font-family:Arial;color:rgb(153,153,153);background-color:transparent;vertical-align:baseline;white-space:pre-wrap" class="">IOS DEVELOPER</span><br class=""></div></span><span class=""><br class=""><div style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" class=""><span style="font-size:11px;font-family:Arial;color:rgb(153,153,153);vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class=""><img src="https://lh5.googleusercontent.com/xMgzw3JkFL3DLkdwyq0WxJzKs_XP57gVVCaBMvgi1FKCjSeue0xdx3JZeCWBlxN4KRHhHOfdvJbc1N-AjTwXcKIq4cjJg9H7iaFpQ8WbO4N3c9Y5dzi19cPOs_owPquuqw" width="250px;" height="53px;" style="border:none" class=""></span></div><div style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" class=""><a href="https://www.remind.com/" style="text-decoration:none" target="_blank" class=""><span style="font-size:11px;font-family:Arial;color:rgb(17,85,204);font-weight:bold;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class="">Remind.com</span></a><span style="font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class=""> </span><span style="font-size:11px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class="">| </span><a href="http://blog.remind.com/" style="text-decoration:none" target="_blank" class=""><span style="font-size:11px;font-family:Arial;color:rgb(17,85,204);text-decoration:underline;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class="">BLOG</span></a><span style="font-size:11px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class=""> | </span><a href="https://twitter.com/remindhq" style="text-decoration:none" target="_blank" class=""><span style="font-size:11px;font-family:Arial;color:rgb(17,85,204);text-decoration:underline;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class="">FOLLOW US</span></a><span style="font-size:11px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class=""> | </span><span style="font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class=""> </span><span style="text-decoration:underline;font-size:11px;font-family:Arial;color:rgb(17,85,204);vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class=""><a href="https://www.facebook.com/remindhq" style="text-decoration:none" target="_blank" class="">LIKE US</a></span></div></span></div></div>
</div></div>
</div></blockquote></div><br class=""></div></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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></body></html>