<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><blockquote type="cite" class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; 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;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><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 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=""></div><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="">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 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=""></div><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="">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></blockquote><div><br class=""></div><div>I would tend to agree, which is part of why I think “future” doesn’t make sense and should stay in the Alternatives Considered but dropped.</div><div><br class=""></div><div>I think the point of extensible/nonexhaustive enums is precisely so we think about what are appropriate defaults, otherwise we would just add a “fatalError” into the compilation of Switches when no case is caught, and that would be the end of this proposal.</div><div><br class=""></div><div>In your example, is there a fair default fallback for this behaviour? Just choose a reasonable default date style and run with it as an appropriate fallback. 95% of the time, there are more reasonable solutions than crashing just because your text on screen line breaks weirdly.</div><div><br class=""></div><div>Only in occasions where either a) the default case makes no sense, or b) I really cannot use a fair default in this calculation, would I fatalError in this case. This would seem to me to be far more reasonable than “I can’t hard code it, stop the presses, crash everything, blow up the world” for most cases. Additionally, it would seem wise for a framework developer to annotate <b class="">why </b>they marked their enum as “nonexhaustive” to give some hint as to a reasonable handling of these cases, where it’s not clearly evident.</div><br class=""><blockquote type="cite" class=""><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;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; 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;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><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<span class="Apple-converted-space"> </span><b class="">anyone</b> 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></div></div></div></blockquote></blockquote></div><br class=""></body></html>