<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 17:57, 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=us-ascii" 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 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></div></blockquote><div><br class=""></div><div>My point is that it's not substantially different. Knowing whether or not the function is <i class="">definitely </i>inlined doesn't change any action you want to take in response to that. (As you noted, this does require knowing whether the library has <i class="">any</i> inlineable code.)</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=""><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></div></blockquote><br class=""></div><div>There's no practical difference to a client between "settings in a library" and "vendor settings shipped with a library", so I guess you're asking for a way to disable inlining code from a particular library? I still think this is something better done on the client side.</div><div><br class=""></div><div>You've brought up a good point, though: <b class="">marking code inlineable needs to be taken very seriously</b>. '@inlineable' and '@fixed_contents' are both placeholder names; they were intended for bikeshedding in the individual proposals to introduce them. Can you come up with something scarier that makes people less likely to use them on a whim? (This is by analogy with things like "UnsafePointer"; "@unsafe_inlineable" isn't quite right but gets at what I mean.)</div><div><br class=""></div><div>('@closed' is also a fragility attribute, but not one someone is likely to misuse, and also one that's <i class="">much</i> less likely to cause a security-level must-update-everything issue. The only case where that would come up is where you can fix the bug with a new value <i class="">entirely</i> on the library side—as in, existing clients don't need to do anything when they see that new value—which seems unlikely.)</div><br class=""><div class="">Jordan</div></body></html>