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

[David Owens II]

> On Feb 10, 2016, at 11:04 PM, Greg Parker via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 10, 2016, at 10:49 PM, Drew Crawford via swift-evolution <swift-evolution at swift.org <mailto: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.

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.

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.

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.

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