<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="">Thanks for the answers, Slava. More inline below.</div><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 21, 2017, at 12:30 AM, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Paul,<div class=""><br class=""></div><div class="">Thanks for reviewing the proposal!<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 9:21 PM, Paul Cantrell <<a href="mailto:cantrell@pobox.com" class="">cantrell@pobox.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><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></div></blockquote><div class=""><br class=""></div>I don’t have a simple answer to this unfortunately, other than the author being really careful, perhaps keeping around build artifacts that were compiled against older versions of the library and testing those.</div><div class=""><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><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></blockquote><div class=""><br class=""></div>That is correct. Another example is if module A publishes an inlinable function, and module B and C depend on A, but B and C were compiled with different versions of A. Then a fourth module D that depends on B and C might see two different published versions of this function.</div></div></div></div></blockquote><div><br class=""></div><div>I am … horrified and intrigued! I suppose C++ headers have always had exactly the same problems, but never having been the maintainer of a C++ library, I never had to worry about it.</div><div><br class=""></div><div>More follow-up “huh” questions:</div><div><br class=""></div><div>1. Presumably the portions of A inlined into B and C remain sensitive to the version-specific memory layout of A? Or will ABI stability mean that the compiler can magically rearrange memory offsets in already-compiled code when the layout changes? (Apologies if this is a too-obvious question; this part of Swift is all a mystery to me.)</div><div><br class=""></div><div>2. Is there some class of statically identifiable breaking changes that the compiler does (or should) detect to flag incompatible inlined code? e.g. some version of A inlined into B references A.foo, then A.foo is deleted in a later version of A, so mixing older B with newer A in a project gives a compile- or link-time error?</div><div><br class=""></div><div>3. Does this need some sort of poison pill feature for other sorts of breaking changes that are not statically detectable? e.g. invariants of a data structure in A change in release 2.0, so the author of A says “it is an error to include A ≥2.0 in any project that inlined any of my code from a version <2.0.” Is this what you were getting at with the mention of @inlinable(2.0) in the proposal? Sounded like that part was about something else, but I didn’t really grasp it tbh.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Or is this not as dangerous as I’m imagining it to be?</div></div></blockquote><div class=""><br class=""></div>It *is* pretty dangerous, which is why I hope this feature is used judiciously by third-party binary frameworks. With source frameworks that are built together with an app and always recompiled, this is less of a concern.</div></div></div></div></blockquote><div><br class=""></div><div>Yes, frameworks+app built simultaneously are clearly the more common case. Though Carthage seems to be champing at the bit to create this problem, since it added a feature to download prebuilt binaries long before ABI stability! I can easily imagining this feature spreading via word of mouth as a “secret go faster switch,” and causing no end of problems in the wild.</div><div class=""><br class=""></div><div class="">Per this and my questions above, a proposal:</div><div class=""><br class=""></div><div class="">It might be safer — and better match the understanding of the typical user — to have @inlinable assume by default that an inlined version of any given method is only valid <b class="">only for the specific version of the module it was inlined from</b>. The compiler would by default flag any version mixing as an error, and require an explicit statement of compatibility intent for each piece of inlinable code to opt in to the danger zone of mixed versions.</div><div class=""><br class=""></div><div class="">Then inlinable code could opt in by specifying some sort of past and future compatibility contract, e.g. “inline-compatible with version 2.x of this module,” perhaps using syntax along the lines of the @available stuff Chris proposed elsewhere in this thread. IOW, my #3 just above would be necessary for the compiler to allow any version mixing whatsoever.</div><div class=""><br class=""></div><div class="">This would have the advantage of making the default behavior of inlinable much more foolproof, and also of nipping in the bud problems of “oh god there are still modules out there that inlined our version 1.0, we can never alter this class.”</div><div class=""><br class=""></div><div class="">Does all that make sense? I’m more than a little out of my depth here.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">Also we are using this feature extensively in the standard library, so as the standard library evolves we will learn and develop best practices, hopefully without too many hiccups :)</div></div></div></blockquote><div><br class=""></div><div>I am very curious to see how that develops!</div><div><br class=""></div><div>Cheers, P</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">Slava</div><div class=""><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Cheers, P</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></body></html>