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

[Jordan Rose]

> On Feb 11, 2016, at 17:57, Drew Crawford <drew at sealedabstract.com> wrote:
> 
> 
>> On Feb 11, 2016, at 7:32 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>> Knowing for sure that your client is inlining isn't extra information over knowing it may inline.
>> 
>> (Technically, a C function marked 'inline' and not 'static' isn't guaranteed to be inlined either, but in practice nobody does that because the rules are awful.)
> 
> I'm referring specifically to the C/C++ case, where "inlining a dynamic library" means "calling a function (or macro) with a body that appears in a .h file".
> 
> In that case I am 100% sure that the function was inlined.  I look at the header file and there it is.
> 
> An argument was advanced that "we do this already in C/C++" We do *something*, but not *this*.

My point is that it's not substantially different. Knowing whether or not the function is definitely inlined doesn't change any action you want to take in response to that. (As you noted, this does require knowing whether the library has any inlineable code.)


> 
>> I really don't think we want average app developers to be accessing types like NSRect indirectly, though, and if you have to opt in to accessing NSRect directly, well, everyone will do it all the time, and it'll cease to be meaningful.
> 
> It seems to me that this can be solved at the xcodeproj level.  Xcode projects have "default settings" and somebody can ship in that template "--inline=UIKit".
> 
> The argument that "we want average app developers to be accessing types like NSRect indirectly" sounds vendor-specific to me, there is a good way here to ship that intuition in a vendor-specific location.

There's no practical difference to a client between "settings in a library" and "vendor settings shipped with a library", so I guess you're asking for a way to disable inlining code from a particular library? I still think this is something better done on the client side.

You've brought up a good point, though: marking code inlineable needs to be taken very seriously. '@inlineable' and '@fixed_contents' are both placeholder names; they were intended for bikeshedding in the individual proposals to introduce them. Can you come up with something scarier that makes people less likely to use them on a whim? (This is by analogy with things like "UnsafePointer"; "@unsafe_inlineable" isn't quite right but gets at what I mean.)

('@closed' is also a fragility attribute, but not one someone is likely to misuse, and also one that's much less likely to cause a security-level must-update-everything issue. The only case where that would come up is where you can fix the bug with a new value entirely on the library side—as in, existing clients don't need to do anything when they see that new value—which seems unlikely.)

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160212/816c068b/attachment.html>