<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><br class=""><blockquote type="cite" class=""><div class="">On Oct 2, 2017, at 11:29 AM, Wallacy 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=""><div dir="ltr" class="">@Slava<div class=""><br class=""></div><div class=""><div class="">If my understanding is correct. If I compile my application with the x.y.z version of a Apple System Framework (like Cocoa). And this framework is updated, several calls from my application to the "new" framework version x.z.a behave like in the x.y.z version for compatibility issues right? I see this being mentioned in the Cocoa documentations sometimes.</div><div class=""><br class=""></div><div class="">Is possible to do this here?</div></div></div></div></blockquote><div><br class=""></div><div>Unfortunately, no. That behavior is manually implemented by the framework authors.</div><div><br class=""></div><div>Dave</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">I usually don't care about non-exhaustive enums. We avoid this even in languages which do not enforce us (using external tools sometimes). But i can understand the "need" in some projects.</div></div><div class=""><br class=""></div><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">Em sáb, 30 de set de 2017 às 21:00, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> escreveu:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_-7281310187273445996Apple-interchange-newline"><div 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" class="">I don’t see how it’s impractical. Quite a lot about how the library should be optimally compiled and used depends on what you plan to do with it. If it’s going to be installed somewhere private and you can guarantee clients will always have the latest version, you can assume all data types are final, @_fixed_layout, @exhaustive, whatever (essentially in-module). An example of that would be a library embedded inside an iOS app bundle. If it’s going to be installed somewhere public and expose some API (like Apple’s frameworks), then you’re going to have to think about binary compatibility.</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" 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" class="">That also means that in-app libraries are optimised as much as they can be, and that resilience-related changes on the declaration side can be limited to the limited set of Swift developers who truly have to care about that.</div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">We do plan on exposing an -enable-resilience flag which basically does what you describe. When a library is built without -enable-resilience, all types are assumed to be fixed layout, etc. However, we don’t want language flags to change language semantics, so exhaustive/nonexhaustive still make sense even when building without resilience, I think. When you switch over a non-exhaustive enum that came from a library built without -enable-resilience, the compiler can still use the most efficient possible access pattern and assume that no new cases will be introduced, but the type checker would still require a default case to be present. The optimizer can then basically strip out the default case as dead code.</div><div class=""><br class=""></div><div class="">Slava</div><br class=""><blockquote type="cite" class=""><div 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" class=""><br class=""></div><span 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;float:none;display:inline!important" class="">- Karl</span></div></blockquote></div><br class=""></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>