<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 20, 2017 at 4:19 PM Ted Kremenek via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<p style="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">The review of "SE-0193 - Cross-module inlining and specialization" begins now and runs through <strong>January 5, 2018</strong>.</p>
<p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">The proposal is available here:</p>
<blockquote style="margin:5px 5px;padding-left:10px;border-left:thin solid #1abc9c">
<p style="margin:0px"><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md</a></p>
</blockquote>
<p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">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">
<p style="margin:0px"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
</blockquote>
<p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">or, if you would like to keep your feedback private, directly to the review manager. </p>
<p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">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">
<p style="margin:0px">Proposal link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md</a><br>
...<br>
Reply text<br>
...<br>
Other replies</p>
</blockquote>
<h3 id="m_5354627898954330086toc_0" style="margin:20px 0px 10px;padding:0px;font-size:18px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">What goes into a review of a proposal?</h3>
<p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">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="margin:15px 0px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">When reviewing a proposal, here are some questions to consider:</p>
<ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">
<li style="margin:0px">
<p style="margin:0px 0px 15px">What is your evaluation of the proposal?</p></li></ul></div></div></blockquote><div>+1. I've worked on a performance-sensitive codebase (Swift protocol buffers) where being able to optimize across module boundaries (using documented features!) would be a huge win.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><li style="margin:0px">
</li>
<li style="margin:0px">
<p style="margin:0px 0px 15px">Is the problem being addressed significant enough to warrant a change to Swift?</p></li></ul></div></div></blockquote><div>Yes. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><li style="margin:0px">
</li>
<li style="margin:0px">
<p style="margin:0px 0px 15px">Does this proposal fit well with the feel and direction of Swift?</p></li></ul></div></div></blockquote><div>Yes, aside from the inevitable name bikeshedding. :)</div><div><br></div><div>I share Xiaodi's view that "@abiPublic" feels like it's coöpting "public" in an odd way, especially when that attribute specifically only applies to internal decls. I could get behind "@abi", but that doesn't quite feel like "enough". "@abiVisible" comes to mind as a possibility—the declaration isn't "public", but it's "visible" in the ABI.</div><div> <br></div><div>A related question (with some background): My assumption is that conditional compilation directives (e.g., #if DEBUG) are resolved *before* an @inlinable function is serialized to the module. Is that correct? In other words, if I have this:</div><div><br></div><div>-----</div><div>// Logger</div><div>@inlinable func log(_ msg: String) {</div><div>#if DEBUG</div><div> print(msg)</div><div>#endif</div><div>}</div><div><br></div><div>// Client</div><div>import Logger</div><div>log("hello")</div><div>-----</div><div><br></div><div>Then when Logger is compiled, the call to print() is *not serialized at all* if DEBUG is undefined, right? (As opposed to serializing the conditional and the body and then using the value of DEBUG in *Client's* compilation to decide whether the code is present when inlined.)</div><div><br></div><div>The reason I ask is because I've been looking at how to tackle logging in Swift—specifically the ability to have debug logging statements completely stripped (including the strings passed to them) in release binaries. This can be achieved today if the logging function is in the same module as the caller and you do an optimized build (and you trust the optimizer to do this reliably); the entire function call and its strings are dropped.</div><div><br></div><div>But if Logger is a separate module, this is no longer possible. @inlinable is one of the ways that I thought this problem could be resolved, but only if the conditionals are also serialized and reapplied against the client's -D flags, and only if the attribute is a *guarantee* from the compiler and not just a *suggestion* to it.</div><div><br></div><div>My hunch is that this is out of scope for this particular proposal (and would be a "side effect" at best rather than a "feature" even if it did work), but I'd love to hear your thoughts on that!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><li style="margin:0px">
</li>
<li style="margin:0px">
<p style="margin:0px 0px 15px">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</p></li></ul></div></div></blockquote><div>Just C++, as described in the proposal. It's unfortunate that C++'s separate header/source structure makes this more elegant in a sense than the Swift solution using attributes, by virtue of just deciding where you place the code. That being said, I can't think of a more elegant approach.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><li style="margin:0px">
</li>
<li style="margin:0px">
<p style="margin:0px 0px 15px">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</p></li></ul></div></div></blockquote><div>Followed earlier discussions and read the proposal.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><li style="margin:0px">
</li>
</ul>
<p style="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">Thanks,<br>
Ted Kremenek<br>
Review Manager</p>
</div>
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><br>
<div></div>
</div>
</div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>