<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="">Hi Karl,<div class=""><br class=""></div><div class="">This is an interesting idea and part of something we would like to explore in the future, which is resilience domains that span more than one module.</div><div class=""><br class=""></div><div class="">However keep in mind that in the current design, resilience is something you opt into when building a library, with a compiler flag. If you don’t pass the flag, there’s no additional indirection, and the flag is off by default.</div><div class=""><br class=""></div><div class="">Note that this does not apply to exhaustive enums — we would like those to always be non-exhaustive by default because we don’t want a compiler flag changing language semantics. However, they will be compiled as if they are exhaustive, meaning the compiler can assume the enum has a fixed layout from the client binary.</div><div class=""><br class=""></div><div class="">Slava<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 6:56 AM, Karl Wagner 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="">There’s a lot of talk in the non-exhaustive enum discussion about the source transition. So let me suggest a possible solution: <b class="">@static imports</b>.</div><div class=""><br class=""></div><div class="">Basically, it seems to me like resilience is going to introduce a lot of indirection, both in generated instructions and in the language. I think that making resilience opt-in on a declaration-by-declaration basis would make it difficult for average programmers to get right, so I support the idea of making Swift libraries resilient-by-default with opt-out abilities when it is obvious from the perspective of the library author that it should be so.</div><div class=""><br class=""></div><div class="">However, Apps are not libraries. Whereas libraries are a kind of theoretical block of code, and you naturally want them to be adaptable to different circumstances, Apps are the concrete things which actually use them. They might have a different perspective on what can be allowed to be non-resilient. Just like an App may be built to be compatible with a particular version of a library, I think it’s reasonable for it to be built expecting other “flavours” of the library, too - including a non-resilient flavour. We already kind of have something like this: executables can import modules as @testable, and those modules are required to be built with the “-enable-testing” flag.</div><div class=""><br class=""></div><div class="">My suggestion is that we create a new kind of import mode, "@static import" and some corresponding compiler flag. When you import a module using @static, you tell the compiler that your App requires exactly the module which it is being compiled alongside. When compiling your regular, resilient-by-default Swift libraries with the special flag, they will be transformed to fix them at their current version and provide later stages of the compiler as much information as if it was within the same module (i.e. applying final, @exhaustive, providing complete SIL, etc). App code will not be able to access “internal” members of the @static library (even though the compiler can see them). We might allow the same attribute to be applied to static libraries from C, which can be similarly freed of resilience concerns.</div><div class=""><br class=""></div><div class="">That would help ease code migration - for this and future resilience-related changes - because you’ll basically get the Swift 4 behaviour back for libraries which you control.</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Courier" class="">// Regular imports. We don’t control these libraries.</font></div></div><div class=""><div class=""><font face="Courier" class="">import Foundation</font></div></div><div class=""><div class=""><font face="Courier" class="">import UIKit</font></div></div><div class=""><div class=""><font face="Courier" class="">// Static imports. We control these; they will be embedded in the final product in some way. Everything is @exhaustive!</font></div></div><div class=""><div class=""><font face="Courier" class="">@static import MyDataModel</font></div></div><div class=""><div class=""><font face="Courier" class="">@static import SharedUIElements</font></div><div class=""><font face="Courier" class=""><br class=""></font></div></div></blockquote>- Karl</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=""></div></body></html>