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

[Drew Crawford]

> On Feb 11, 2016, at 6:26 PM, Jordan Rose <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.

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.

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160211/d6736d2b/attachment.html>