<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Johannes,<div class=""><br class=""></div><div class="">Thanks for reviewing this proposal!<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""></div></blockquote><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">The library I'm working on will presumably never have stable ABI as you'd naturally build it with your application. However we also don't want to miss on the cross-module optimisation & specialisation and I suspect there are quite a few (mostly open-source) libraries in the same space. I'm pretty sure everybody would just end up littering their code with @abiPublic/@inlinable (or the @available(...) syntax Chris Lattner proposed) without actually meaning that.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Summing up: I think this feature is crucial but shouldn't come without a compiler "where all declarations become implicitly @inlinable, and all private and internal declarations become @abiPublic". I really don't want to litter the code with attributes that aren't what I mean. (basically `swift build --global-resilience-domain`) Having this compiler mode also makes these attributes IMHO really niche and therefore I can only sympathise with's Chris' sentiment to not litter the global attribute namespace.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div>I agree that a ‘completely non-resilient’ compiler mode would be great when building libraries that are always shipped together, and I hope Swift gains such a feature one day, possibly built on top of the very infrastructure used to implement this proposal!</div><div><br class=""></div><div>However, the goal of this proposal is to formalize some language features that already exist and are used by the standard library. Clearly making everything fragile is a non-starter for the standard library in an ABI-stable world.</div><div><br class=""></div><div>I do hope that this attribute is not abused in the manner in which you describe, but I’m not sure the potential for abuse is reason enough to not run the proposal — people are already using the underscored attribute today, risking source breakage and bugs due to insufficient test coverage in the future.</div><div><br class=""><blockquote type="cite" class=""><div class=""><span class="" style="float: none; display: inline !important;">C(++) as described in the proposal and Haskell (</span><a href="https://wiki.haskell.org/Inlining_and_Specialisation" class="">https://wiki.haskell.org/Inlining_and_Specialisation</a><span class="" style="float: none; display: inline !important;">), where {-# INLINABLE myFunction #-} (quoting the docs) causes exactly two things to happens.</span><br class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class="Apple-tab-span" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: pre; word-spacing: 0px; -webkit-text-stroke-width: 0px;"> </span><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">• The function's (exact) definition is included in the interface file for the module.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class="Apple-tab-span" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: pre; word-spacing: 0px; -webkit-text-stroke-width: 0px;"> </span><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">• The function will be specialised at use sites -- even across modules.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Note that [the Haskell compiler] GHC is no more keen to inline an INLINABLE function than any other.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div>Note that Swift’s compiler is the same — @inlinable does not influence optimizer decisions to inline or not.</div><div><br class=""></div><div>Also currently the proposal is implemented by binary serialization of the SIL IR, but nothing in it precludes serializing inlinable function bodies as source code in the future — in fact we are likely to go in that direction if we implement the proposed textual ‘stable’ module format.</div><div><br class=""></div><div>Slava</div><br class=""></div></body></html>