[swift-evolution] [RFC] "Library Evolution Support in Swift ('Resilience')"

Greg Parker gparker at apple.com
Thu Feb 11 01:04:52 CST 2016

> On Feb 10, 2016, at 10:49 PM, Drew Crawford via swift-evolution <swift-evolution at swift.org> wrote:
> When someone vendors or statically links a library, they know what they are getting into.  I mean, sometimes people do silly things, but they should know.
> 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.

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. 

Yes, @inlineable must be applied with care. The capability is too useful - especially for systems-level programming - to go without it.

Greg Parker     gparker at apple.com     Runtime Wrangler

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160210/fa53eefa/attachment.html>

More information about the swift-evolution mailing list