<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 6, 2017, at 8:50 AM, Rod Brown &lt;<a href="mailto:rodney.brown6@icloud.com" class="">rodney.brown6@icloud.com</a>&gt; 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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 6 Sep 2017, at 2:31 pm, Charlie Monroe &lt;<a href="mailto:charlie@charliemonroe.net" class="">charlie@charliemonroe.net</a>&gt; wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 6, 2017, at 5:44 AM, Rod Brown via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 10px; 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 think what you’re really asking for here is the “future” case mentioned in the Alternatives Considered section. I think that Jordan makes a good point that this would result in untestable code, which is bad practice. While the lack of clear highlighting of non-exhaustive cases is undesirable, I think untestable code is a much larger problem here.</div></div></div></blockquote><div class=""><br class=""></div><div class="">This is generally the switch! that I've suggested listed in alternatives as well - that generally brings current behavior. For a project that is regularly maintained, I believe that this makes sense given that the enums are only likely to change once a year at most (with new OS releases)…</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I see the logic of this position, but it traps at cases which are unforeseen unrelated to OS releases. As this proposal notes, there are cases that Apple uses internal of their frameworks that they consider private may still be passed through your API.</div><div class=""><br class=""></div><div class="">For example, if there was a new button type, and you enumerated all public types in your method, but UIKit had a private custom button type, you couldn’t catch on it, nor would you have any idea that it existed. This isn’t related to the release cycle timing, but you’re still going to start crashing despite the fact that you believe you’ve exhaustively handled all cases.</div></div></div></div></blockquote><div><br class=""></div><div>Fully understood, though when you are in the middle of some calculation, you are unlikely to do anything by fatalError in the "future" case...</div><div><br class=""></div><div>Imagine e.g. your DateFormatter and you get a new Style in the formatting - what do you do? Fallback on a different one? I personally would simply call fatalError in the future case anyway...</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">Also, we need to be thinking bigger than just the Apple Ecosystem. While Swift started on the Mac and iOS, this is hardly guaranteed, nor are release timings. Also, just because the dynamic frameworks update at regular intervals now, doesn’t mean the same will happen on Linux, where a dynamically linked framework could just update without anyone knowing. Part of the consideration of ABI stability isn’t just for Apple to ship frameworks, but for <b class="">anyone</b>&nbsp;to ship frameworks that are not contained within the signed bundle of the application. It is short sighted to say “well, this works for us right now” in my opinion. Part of this discussion is to mature Swift away from these kinds of assumptions (Apple, Obj-C, etc).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 10px; 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=""><br class=""></div><div class="">Either way we need a way to handle forward compatibility for our code when cases get added to external frameworks, that much is clear. Swift is broken in regards to this, and we need to handle it<span class="Apple-converted-space">&nbsp;</span><b class="">somehow.<span class="Apple-converted-space">&nbsp;</span></b>I’m hoping you’re not suggesting that we just don’t make this change at all. We need this for forward compatibility for framework development with Swift.</div><div class="">_________________________________</div></div><span style="font-family: Helvetica; font-size: 10px; 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; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 10px; 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=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 10px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 10px; 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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 10px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>