<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 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><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><br class=""></div><div>Yes, @inlineable must be applied with care. The capability is too useful - especially for systems-level programming - to go without it.</div><div><br class=""></div><div><br class=""></div><div>-- </div><div>Greg Parker <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a> Runtime Wrangler</div><div><br class=""></div><div><br class=""></div></body></html>