<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=""><div><blockquote type="cite" class=""><div class="">On Jan 12, 2018, at 6:47 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="">I feel like we’re talking past each other right now, so I’ll give a concrete example:<div class=""><br class=""></div><div class="">Let’s say MyAwesomeFramework.framework defines this enum:</div><div class=""><br class=""></div><div class="">enum Access {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case none</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case readOnly</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case readWrite</div><div class="">}</div><div class=""><br class=""></div><div class="">This framework is compiled, built, and embedded in to MyAwesomeApp.app/Frameworks.</div><div class=""><br class=""></div><div class="">Somewhere in MyAwesomeApp, I switch on the access of a thing:</div><div class=""><br class=""></div><div class="">switch aThing.access {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case .none: break</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case .readOnly: print(“I can read”)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case .readWrite: print(“I can write”)</div><div class="">}</div><div class=""><br class=""></div><div class="">Let’s here observe some things:</div><div class=""><br class=""></div><div class="">1️⃣ the enum “Access” is *not* declared as frozen, because it might get a new case in the future (such as “writeOnly”)</div><div class="">2️⃣ the switch on an Access value is exhaustive</div><div class="">3️⃣ under the proposal, I’m going to get a warning on the switch because Access is not frozen. That warning will tell me to add “unknown case:”</div><div class=""><br class=""></div><div class="">This is the problem I’m talking about. The warning I’ll get on the switch is technically correct (I’m switching on a non-frozen enum), but semantically incorrect (it’s ok because the framework CANNOT introduce a new case without recompilation of the switch statement, because they are packaged together). The compiler will tell me to add an unknown case statement to the switch when it will be completely unnecessary. Since MyAwesomeFramework.framework is embedded in my app, there is no binary compatibility concern here, and I will never come across an unknown case.</div><div class=""><br class=""></div><div class="">I think this false positive is going to be very common, because lots of people embed frameworks in their apps, and those frameworks declare enums. Until the frameworks are updated to freeze the enums, the app authors will be forced to add “unknown case” statements to their switches for places where it is entirely unnecessary. (This brings up the question: does this proposal include a fixit to remove an “unknown case” statement from switches where it’s unnecessary?)</div><div class=""><br class=""></div><div class="">So, what I’m asking for is a part in the proposal (likely under “Future Directions”) where you acknowledge this problem (the “false positive problem for embedded modules”) and list it as something we’d like to solve in the future.</div></div></div></blockquote><div><br class=""></div>I agree that it's important to discuss this in the proposal.</div><div><br class=""></div><div>I think the point that Jordan is trying to make is that this kind of resilience problem can come up as a <i class="">source</i>-compatibility issue, not just a <i class="">binary</i>-compatibility issue. Of course an <i class="">app</i> can be version-locked to its non-OS dependencies and nobody will care. However, it's problematic for a <i class="">library</i> to be version-locked to its dependencies even if both the library and its dependencies are only ever distributed as source: you ought to be able to upgrade the dependencies without having to revise all the dependent libraries. If our library ecosystem doesn't let you pull a new version of BaseLib without simultaneously pulling new versions of everything else you use that requires BaseLib — or, alternatively, hand-fixing them all yourself if that library hasn't gotten updated yet — that's a pretty frustrating experience.</div><div><br class=""></div><div>Conversely, an app ought to be able to be version-locked to its non-OS dependencies whether they're binaries or source. So this really has almost nothing to do with binary vs. source distribution and everything to do with whether version-locking makes sense for a specific project.</div><div><br class=""></div><div>John.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Dave<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 12, 2018, at 4:27 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=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 12, 2018, at 4:22 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="">No, it's "Revision-locked imports”.</div></div></blockquote><br class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Ah, yeah I can see how the rev-locked imports is a variation on “I’ve copied in this library”.</div></div></div><div class=""><div class=""><br class=""><blockquote type="cite" class=""></blockquote></div></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">A source-breaking change is one in which updating the library <i class="">at compile time</i> will break clients <i class="">at compile time.</i> That's relevant for libraries distributed with an app as well as for libraries that are part of the OS. You may not care, but I do, and I think other package authors will too.</div></div></div></blockquote><div class=""><br class=""></div><div class="">??? Of course I care about getting warnings when I’ve chosen to update a dependency. Where did I ever imply otherwise?</div><div class=""><br class=""></div><div class="">What I’m saying is that if I’m embedding such a library in my app *now* and I’m importing it *now*, I shouldn’t get a warning about handling unknown cases off non-frozen enums *now*. </div><div class=""><br class=""></div><div class="">And if I am going to see such warnings now, then the document needs to include how those “false positives” will be eliminated in the future.</div><div class=""><br class=""></div><div class="">Dave</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>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>