<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 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><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>Jordan</div><br class=""></body></html>