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

[Jordan Rose]

> On Feb 11, 2016, at 15:56, David Owens II <david at owensd.io> wrote:
> 
> 
>> On Feb 11, 2016, at 2:39 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>> 
>>> On Feb 11, 2016, at 13:54, Drew Crawford via swift-evolution <swift-evolution at swift.org <mailto: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.
> 
> Do you have any metrics on how often the disable safety metrics are used when compiling swift code?
> 
> C++ isn't know for being the bastion of doing versioning correctly. I agree it has the speed target that hopefully Swift can get to.
> 
> As for C#, unless you are talking about something I don't know about, ngen and JIT (runtime) are the only ways that the code will be inlined. However, when the assembly changes, that should invalidate the ngen'd image forcing it to be regenerated. Hence the entire feature for the TargetedPatchingOptOut on system framework dlls (selective replacement of the ngen'd images).
> 
> In any case, for apps, the scenario is largely irrelevant. To ship and update to that, I must do a recompile. This is mostly true for all ship mechanism on Apple platforms now any because.
> 
> Maybe it's a narrow enough surface area where this would actually be a practical issue such that it's largely irrelevant...

Well, Apple itself will be using this model, so if there's a bug in an inlineable function in Cocoa, this could make a difference.

Unfortunately, I can't share any metrics about -O vs. -Ounchecked.

Jordan

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