<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 10, 2016, at 11:04 PM, Greg Parker 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; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 10, 2016, at 10:49 PM, Drew Crawford 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; -webkit-line-break: after-white-space;" class="">When someone vendors or statically links a library, they <i class="">know</i> what they are getting into. I mean, sometimes people do silly things, but they <i class="">should</i> know.<div class=""><br class=""></div><div class="">Whereas "inlining across dynamically linked libraries" is a novel Swiftism (Or it may be a Rustism as well but in any case) nobody expects it. They will assume that replacing the dynamic library actually replaces the dynamic library's code, because that is the social contract for dynamic linkage.</div></div></div></blockquote><div class=""><br class=""></div>C and C++ do it too, of course: pretty much anything you put in a C or C++ header file is fair game for inlining. The implementations of dispatch_once() and NSMakeRect() are two examples off the top of my head. Nothing you do to libdispatch.dylib or Foundation.framework will affect a previously-compiled caller of those functions. </div><div class=""><br class=""></div><div class="">Yes, @inlineable must be applied with care. The capability is too useful - especially for systems-level programming - to go without it.</div></div></div></blockquote><div><br class=""></div><div>I don't think anyone is arguing that @inlineable shouldn't be available, but we are already heading down the path of "some features" are more important than resilience, so we'll allow it. That seems to be defeat purpose of resiliency in the first place.</div></div><br class=""><div class="">I personally think it's a very fair trade-off to disallow @inlineable code to be inlined from a dynamic dll by default. Now, that doesn't mean that the developer couldn't add a link flag `--super-nonresilient-i-know-what-im-doing` when pulling in certain DLLs. That's an explicit statement that the developer is choosing to break resilience. The important part is that it's the developer consuming the DLL making the choice vs. the developer of the DLL making that choice for everyone.</div><div class=""><br class=""></div><div class="">Further, this can now be a runtime warning/error when loading a version of the DLL that is not the same one that was linked against originally. Another option is to hash the inlined function and if those hashes don't match error.</div><div class=""><br class=""></div><div class="">-David</div></body></html>