<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 7:32 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=""><div 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;" class="">Knowing for sure that your client is inlining isn't extra information over knowing it may inline.</div><div 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;" class=""><br class=""></div><div 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;" class="">(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></blockquote></div><br class=""><div class="">I'm referring specifically to the C/C++ case, where "inlining a dynamic library" means "calling a function (or macro) with a body that appears in a .h file".</div><div class=""><br class=""></div><div class="">In that case I am 100% sure that the function was inlined. I look at the header file and there it is.</div><div class=""><br class=""></div><div class="">An argument was advanced that "we do this already in C/C++" We do *<i class="">something*</i>, but not *this*.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="font-family: HelveticaNeue;" class="">I </span><i class="" style="font-family: HelveticaNeue;">really</i><span style="font-family: HelveticaNeue;" class=""> don't think we want average app developers to be accessing types like NSRect indirectly, though, and if you have to </span><i class="" style="font-family: HelveticaNeue;">opt in</i><span style="font-family: HelveticaNeue;" class=""> to accessing NSRect directly, well, everyone will do it all the time, and it'll cease to be meaningful.</span></blockquote><br class=""></div><div class="">It seems to me that this can be solved at the xcodeproj level. Xcode projects have "default settings" and somebody can ship in that template "--inline=UIKit".</div><div class=""><br class=""></div><div class="">The argument that "we want average app developers to be accessing types like NSRect indirectly" sounds vendor-specific to me, there is a good way here to ship that intuition in a vendor-specific location.</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>