<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 11, 2016, at 6:26 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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?</span></div></blockquote></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">I don't think I trust any client to decide which parts of the library are "safe, probably"</blockquote></div><div class=""><br class=""></div><div class="">Similarly, I don't trust library authors to decide which parts of their libraries are safe for me to inline in my client.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></body></html>