<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=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 24, 2017, at 8:33 PM, Howard Lovatt <<a href="mailto:howard.lovatt@gmail.com" class="">howard.lovatt@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">I was making two seperate points: 1. Annotating which parts of a public APIs are stable should not be necessary and 2. Inlining should be left to the compiler. <div class=""><br class=""></div><div class="">Point 1: If you had a module system that was versioned then a public declaration should be taken as stable across all minor releases. IE You can only add public declarations, not remove or change, for versions 1.x.x compared to 1.0.0. <div class=""><br class=""></div><div class="">That way you don’t need to separately annotate which bits of the API are stable. All the public API is stable. </div></div></div></div></blockquote><div><br class=""></div><div>The @abiPublic attribute as described in the proposal is only meant to be used for *internal* declarations which can be referenced from inlinable functions. Public functions are not annotated, and indeed as you describe, you cannot remove any public declaration if you’re publishing a source-stable or binary-stable library.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class="">Point 2: Functions that the compiler of a module decrees are potentially inlinable should be published using SIL or LLVM so that they can be inlined when the module is used either at compile time or runtime.</div></div></div></div></blockquote><div><br class=""></div><div>The reason the compiler cannot make the decision about what to inline across module boundaries is that this can end up exposing implementation details of the module. If everything can be inlined, you’re effectively doing static linking, which eliminates the ability to ship updated versions of a binary framework.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""> It is important that it is something simple like SIL or LLVM to make inlining light weight. That way the module compiler can be quite speculative about inlining and make many functions available for inlining. In contrast the compiler consuming the library can be conservative with a runtime back up if in doubt. IE if the function is marginal then don’t inline until runtime has proven that inlining is worth while. </div></div></div></div></blockquote><div><br class=""></div>This is already how the optimizer works today. @inlinable annotations are not necessary to inline within a module, where the compiler makes all the decisions based on cost heuristics. Across modules @inlinable does not force any inlining either, it just makes the body available for the optimizer, if it decides to make use of it.</div><div><br class=""></div><div>Slava</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><br class=""><div class="">-- Howard. </div><div class=""><br class="">On 24 Dec 2017, at 9:53 pm, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Dec 24, 2017, at 3:04 PM, Howard Lovatt 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=utf-8" class=""><div dir="auto" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Proposal link:</span><span style="background-color: rgba(255, 255, 255, 0);" class=""> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="5" style="background-color: rgba(255, 255, 255, 0);" class="">https://github.com/apple/swift-evolution/blob/</a><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md</a><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="5" class="" style="background-color: rgba(255, 255, 255, 0);">master/proposals/0193-cross-module-inlining-and-specialization.md</a></div></div></blockquote></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px;" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">What is your evaluation of <a href="x-apple-data-detectors://7" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="misc" x-apple-data-detectors-result="7" style="-webkit-text-decoration-color: rgba(0, 0, 0, 0.258824);" class="">the proposal</a>?</span></p><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">-1</span></p><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">The proposal puts all the emphasis on the programmer. It is better for the compiler to decide if something is to be inclined both across modules and within modules. </span></p><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">If something is made public then it should be fixed for a given major version number. No need for extra annotation. </span></p><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">A module system that allows versioning is a better solution. </span></p><div class=""><br class=""></div></li></ul></div></div></blockquote>Can you explain your proposed solution in more detail?</div><div class=""><br class=""><blockquote type="cite" class=""><div dir="auto" class=""><ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px;" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">No, cluttering up declarations is completely against the clarity of Swift. For example who other than people on this group will understand @inline(never) @inlinable. </span></p><div class=""><br class=""></div></li></ul></div></blockquote>We don’t expect this attribute to be used frequently in third-party frameworks. @inline(never) @inlinable is a weird combination, but I hope that @inline(never) is used even less frequently. In fact other than debugging it probably doesn’t have much purpose at all, and it would be nice to deprecate it some day.<br class=""><blockquote type="cite" class=""><div dir="auto" class=""><ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px;" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span></p><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Yes C and C++ and found the equivalent of these annotations problematic. In Java they eliminated all this and let the compiler do the work. In practice this works much better. </span></p><div class=""><br class=""></div></li></ul></div></blockquote>The Java approach works because there’s no separate compilation — having a JIT means the optimizer is free to inline across module boundaries without any resilience considerations. This doesn’t fit with Swift’s compilation model though.</div><div class=""><br class=""></div><div class="">Slava</div><br class=""></div></blockquote></div></div></div></div></blockquote></div><br class=""></body></html>