<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Two points:<div><br></div><div>1. I like Chris’s suggestion of #unknown and in particular that it is distinct from default. </div><div><br></div><div>2. All the discussion is about a framework adding a case, what about when a framework deletes a case?<br><br><div id="AppleMailSignature">-- Howard.</div><div><br>On 10 Jan 2018, at 1:41 pm, Dave DeLong via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 10, 2018, at 1:29 PM, Dave DeLong 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=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 10, 2018, at 1:05 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=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><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=""><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="">That said, it sounds like people are happier with `case #unknown` than `unknown case`, and that leaves things a little more consistent if we ever do expand it to other pattern positions, so I'll change the proposal revision to use that spelling. (And if anyone comes up with a nicer spelling, great!)</div></blockquote><br class=""></div><div class="">Thanks!</div></div></div></blockquote><br class=""></div><div class="">Updated! <a href="https://github.com/apple/swift-evolution/pull/777" class="">https://github.com/apple/swift-evolution/pull/777</a>. Also tried to clarify some of the points on why I'm leery about #unknown as an arbitrary pattern, at least for now.</div></div></div></blockquote><br class=""></div><div class="">Hi Jordan,</div><div class=""><br class=""></div><div class="">After a long and hard reading, I will conditionally +1 this:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">I agree that this is a problem that “needs" to be solved. (“Needs” is subjective, because as you correctly point out, there are other languages that don’t do this and seem to be relatively OK with that)</li><li class="">I am ok with the @frozen moniker on enums</li><li class="">I am ok with the “#unknown” syntax</li><li class="">I am therefore generally ok with the proposed solution</li></ul><div class=""><br class=""></div><div class="">BUT:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">I think the application of the warnings is still overly broad. The frozenness of an enum is only a problem for enums that come from dynamically linked modules that are external to my built project.</li></ul></div><div class=""><br class=""></div><div class="">Therefore I’d like to see stuff regarding:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">future directions for how we can refine the behavior and tooling around frozen enums, specifically</li><li class="">“statically” linking libraries (ie, the “import Module1 @ 12.1.2” stuff, aka “version locking"), because statically linking should eliminate frozenness concerns</li><li class="">embedded modules not producing warnings in the future, because embedded modules only change when the app author decides</li><li class="">ruminations on improving tooling for yelling at a developer if they “unfreeze” an enum in between versions (ie, a reduction of the SemVer conversation)</li></ul><div class=""><br class=""></div></div><div class="">Because version locking and knowledge of embedding modules doesn’t currently exist, we’re forced to deal with the over-applicability of frozenness that shouldn’t be necessary. Getting those in would go a long way towards getting this feature scoped down to where it properly belongs in the app development workflow.</div></div></div></div></blockquote><br class=""></div><div>In other words, the current solution will produce a bunch of false positives, and I’d like to see stuff in the proposal about how those false positives will be addressed.</div><div><br class=""></div><div>Dave</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>