<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 16:56, Drew Crawford <<a href="mailto:drew@sealedabstract.com" class="">drew@sealedabstract.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><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></div></blockquote><div><br class=""></div><div>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 <i class="">it</i> was compiled with. Knowing for sure that your client is inlining isn't extra information over knowing it may inline.</div><div><br class=""></div><div>(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.)</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></div></blockquote><br class=""></div><div>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 <i class="">that</i> function calls <i class="">other</i> inlineable functions.</div><div><br class=""></div><div>I <i class="">really</i> don't think we want average app developers to be accessing types like NSRect indirectly, though, and if you have to <i class="">opt in</i> to accessing NSRect directly, well, everyone will do it all the time, and it'll cease to be meaningful.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>