[swift-evolution] [RFC] "Library Evolution Support in Swift ('Resilience')"
drew at sealedabstract.com
Thu Feb 11 18:56:02 CST 2016
> 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...
More information about the swift-evolution