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

[Jordan Rose]

> On Feb 11, 2016, at 13:54, Drew Crawford via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 11, 2016, at 11:53 AM, David Owens II <david at owensd.io <mailto:david at owensd.io>> wrote:
>> 
>> 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.
> 
> +2
> 
> IMO disabling inlining of DLLs should clearly be the default, and there should be some "I know what I'm doing" flag for folks who are willing to take on the burden of vendoring their library as if it were static.


You're using inlineable code today in Cocoa: dispatch_once's fast-path, the geometry functions from CoreGraphics to SceneKit, and every NS_OPTIONS enum that has an "all" case. It is a performance vs. flexibility tradeoff, but an incredibly important one. In Swift we definitely don't want to sacrifice flexibility by default, but it has to be an option if we want Swift to be a viable replacement for things traditionally done with C or C++. "Inlining across dynamic libraries" has been around for decades with C, C++, and C#.

I'm skeptical that anyone will actually use your hypothetical "use this library without treating anything as fragile, even if I could" setting; most clients just want as much performance as they can get. But it would be implementable.

Jordan

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