<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 2:39 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=""><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 13:54, Drew Crawford via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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 11:53 AM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</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="">I personally think it's a very fair trade-off to disallow @inlineable code to be inlined from a dynamic dll by default. Now, that doesn't mean that the developer couldn't add a link flag `--super-nonresilient-i-know-what-im-doing` when pulling in certain DLLs. That's an explicit statement that the developer is choosing to break resilience. The important part is that it's the developer consuming the DLL making the choice vs. the developer of the DLL making that choice for everyone.</span></div></blockquote></div><br class=""><div class="">+2</div><div class=""><br class=""></div><div class="">IMO disabling inlining of DLLs should clearly be the default, and there should be some "I know what I'm doing" flag for folks who are willing to take on the burden of vendoring their library as if it were static.</div></div></div></blockquote></div><div class=""><br class=""></div><div class="">You're using inlineable code today in Cocoa: dispatch_once's fast-path, the geometry functions from CoreGraphics to SceneKit, and every NS_OPTIONS enum that has an "all" case. It <i class="">is</i> a performance vs. flexibility tradeoff, but an incredibly important one. In Swift we definitely don't want to sacrifice flexibility <i class="">by default,</i> but it has to be an option if we want Swift to be a viable replacement for things traditionally done with C or C++. "Inlining across dynamic libraries" has been around for decades with C, C++, and C#.</div><div class=""><br class=""></div><div class="">I'm skeptical that anyone will actually <i class="">use</i> your hypothetical "use this library without treating anything as fragile, even if I could" setting; most clients just want as much performance as they can get. But it would be implementable.</div></div></div></blockquote><br class=""></div><div>Do you have any metrics on how often the disable safety metrics are used when compiling swift code?</div><div><br class=""></div><div>C++ isn't know for being the bastion of doing versioning correctly. I agree it has the speed target that hopefully Swift can get to.</div><div><br class=""></div><div>As for C#, unless you are talking about something I don't know about, ngen and JIT (runtime) are the only ways that the code will be inlined. However, when the assembly changes, that should invalidate the ngen'd image forcing it to be regenerated. Hence the entire feature for the TargetedPatchingOptOut on system framework dlls (selective replacement of the ngen'd images).</div><div><br class=""></div><div>In any case, for apps, the scenario is largely irrelevant. To ship and update to that, I must do a recompile. This is mostly true for all ship mechanism on Apple platforms now any because.</div><div><br class=""></div><div>Maybe it's a narrow enough surface area where this would actually be a practical issue such that it's largely irrelevant...</div><div><br class=""></div><div>-David</div><div><br class=""></div></body></html>