<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=""><div class="">This seems like a problem worth solving — or rather worth making the solution public, since this is already in use as an undocumented feature!</div><div class=""><br class=""></div><div class="">A concern: how would a library author reason about, and check for bugs in, the combinatorial explosion of old and new implementations that could exist simultaneously with this feature in use?</div><div class=""><br class=""></div><div class="">The proposal touches on this in the “Effect on API resilience” section:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Any changes to the body of a declaration annotated as @inlinable should be considered very carefully. As a general guideline, we feel that @inlinable makes the most sense with "obviously correct" algorithms which manipulate other data types abstractly through protocols, so that any future changes to an @inlinable declaration are optimizations that do not change observed behavior.<br class=""></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class="">Also, an @inlinable function implementation must be prepared to interact with multiple versions of the same function linked into a single binary. For example, if a hashing function is @inlinable, the hash algorithm must not be changed to avoid introducing inconsistency.</blockquote></div><div class=""><br class=""></div><div class="">That last paragraph gives a relatively trivial example, but the implications are daunting! If I understand correctly, anything in a library that uses any @inlinable or @abiPublic code must be prepared to deal with every possible combination of every past published implementation of that code. And that “every possible combination” is not per function, but per…call site?</div><div class=""><br class=""></div><div class="">Suppose we have this:</div><div class=""><br class=""></div><div class=""><div class=""> // Module A</div><div class=""><br class=""></div><div class=""> @inlineable func bar() { ... }</div><div class=""><br class=""></div><div class=""> // Module B</div><div class=""><br class=""></div><div class=""> @inlineable func foo() {</div><div class=""> if whatever {</div><div class=""> bar(0) // compiler decides to inline this...</div><div class=""> } else {</div><div class=""> bar(1) // ...but not this, for whatever reason</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class=""> // Module C</div><div class=""><br class=""></div><div class=""> func baz() {</div><div class=""> foo()</div><div class=""> }</div></div><div class=""><br class=""></div><div class="">…and suppose B was compiled against A v1.0 but C was compiled against A v2.0. Then, if I’m following, it’s possible for bar(0) to use the 1.0 implementation but bar(1) to use the 2.0 impl. Do I have that right? It seems to be what the hash value example is getting at.</div><div class=""><br class=""></div><div class="">The potential for undetected bugs seems enormous. I wonder if there’s a need for extra assistance for library authors, e.g.:</div><div class=""><br class=""></div><div class="">• A tool that allows one to take binaries for multiple versions of a lib with inlinables, and repeatedly runs a test suite using a randomly selected version of each inlinable func every time it’s used</div><div class=""><br class=""></div><div class="">• Static sanity checks (but what would they be?)</div><div class=""><br class=""></div><div class="">• Strict module version match conditions on @inlineable (but then dependency hell takes up residence in the compiler?)</div><div class=""><br class=""></div><div class="">• Bail on compilation and JIT everything (ha)</div><div class=""><br class=""></div><div class="">Or is this not as dangerous as I’m imagining it to be?</div><div class=""><br class=""></div><div class="">Cheers, P</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 6:19 PM, Ted Kremenek 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="">
<title class=""></title>
<div class="">
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class=""><p style="-webkit-print-color-adjust: exact; margin-right: 0px; margin-bottom: 15px; margin-left: 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); margin-top: 0px !important;" class="">The review of "SE-0193 - Cross-module inlining and specialization" begins now and runs through <strong style="-webkit-print-color-adjust: exact;" class="">January 5, 2018</strong>.</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">The proposal is available here:</p>
<blockquote style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;" class=""><div style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><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></div>
</blockquote><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Reviews are an important part of the Swift evolution process. All review feedback should be sent to the swift-evolution mailing list at:</p>
<blockquote style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;" class=""><div style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div>
</blockquote><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">or, if you would like to keep your feedback private, directly to the review manager. </p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">When replying, please try to keep the proposal link at the top of the message:</p>
<blockquote style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;" class=""><div style="-webkit-print-color-adjust: exact; margin: 0px;" class="">Proposal link: <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><br style="-webkit-print-color-adjust: exact;" class="">
...<br style="-webkit-print-color-adjust: exact;" class="">
Reply text<br style="-webkit-print-color-adjust: exact;" class="">
...<br style="-webkit-print-color-adjust: exact;" class="">
Other replies</div>
</blockquote>
<h3 id="toc_0" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 18px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">What goes into a review of a proposal?</h3><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. </p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">When reviewing a proposal, here are some questions to consider:</p>
<ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">
<li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">What is your evaluation of the proposal?</p>
</li>
<li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Is the problem being addressed significant enough to warrant a change to Swift?</p>
</li>
<li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Does this proposal fit well with the feel and direction of Swift?</p>
</li>
<li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</p>
</li>
<li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</p>
</li>
</ul><p style="-webkit-print-color-adjust: exact; margin-top: 15px; margin-right: 0px; margin-left: 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); margin-bottom: 0px !important;" class="">Thanks,<br style="-webkit-print-color-adjust: exact;" class="">
Ted Kremenek<br style="-webkit-print-color-adjust: exact;" class="">
Review Manager</p>
</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class=""><br class="">
<div class=""></div>
</div>
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>