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

[Jordan Rose]

> On Feb 11, 2016, at 16:56, Drew Crawford <drew at sealedabstract.com> wrote:
> 
> 
>> On Feb 11, 2016, at 6:26 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>> If it does, what are you going to do about it? Are you going to try to make a distinction on a per-function basis whether or not it's safe to inline it?
> 
> 
> Backing up, the argument was advanced that inlining is fine because it's equivalent to C/C++.  C/C++ has a way to determine with certainty if a function will be inlined (e.g. appears in the header) so either we are equivalent to C/C++ and we can also determine with certainty or we are not.  If we are not, then arguments of the form "C/C++ does it" when actually it has a similar but subtly different feature begin to lose ground.

That's true, but it still doesn't mean all clients will use the same implementation. If different client libraries are compiled against different versions of a base library, they will each inline the version they were compiled with, and of course the base library itself will use the version it was compiled with. 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.)


> 
> But to answer the question about "what I would do about it", I might not call the function, if I knew it to be inlined.  Another thing I have done in C/C++ is vendor the inline function, and implement it slightly more optimally based on things I know at the callsite, so that is a special case of not calling it.

There may not be another way to accomplish what you want. For instance, inlineable functions are permitted to access non-public properties of a struct; like in C++, there is no way to get at those properties otherwise. You're right that you could introduce another intermediate library, though.


> 
>> I don't think I trust any client to decide which parts of the library are "safe, probably"
> 
> 
> Similarly, I don't trust library authors to decide which parts of their libraries are safe for me to inline in my client.
> 
> I think this may be a difference in perspective, e.g. if one works at Apple then one may receive many bug reports of the form "silly app developer, don't use UIKit this way" leading to a general mistrust of clients.  Meanwhile, if one has hundreds of filed radars still open (ಠ_ಠ) one might develop a general mistrust of library authors.
> 
> To me it seems that this trust problem could be resolved were inlining to be an opt-in feature for each party.  The library author should opt-in at the function level, and the client should opt in at least at the library level, and I would prefer at the callsite.

Sorry, my point wasn't "library authors know better than client developers"; it's that trying to make decisions about specific functions isn't sound. It's possible the body of one function makes assumptions based on other (guaranteed, version-independent) knowledge about the library, the simplest form being that that function calls other inlineable functions.

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.

Jordan

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