<div dir="ltr">On Fri, Dec 22, 2017 at 2:08 AM, Slava Pestov via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi Chris,<div><br></div><div><span class="gmail-">Thanks for reviewing the proposal!<br></span><div><span class="gmail-"><br><blockquote type="cite"><div>On Dec 20, 2017, at 11:14 PM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="gmail-m_-7650217660453785746Apple-interchange-newline"><div><div 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"><blockquote type="cite"><div>On Dec 20, 2017, at 4:19 PM, Ted Kremenek &lt;<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>&gt; wrote:</div><br class="gmail-m_-7650217660453785746Apple-interchange-newline"><div><div><div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><p style="margin:0px 0px 15px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">The review of &quot;SE-0193 - Cross-module inlining and specialization&quot; 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;padding-left:10px;border-left-width:thin;border-left-style:solid;border-left-color:rgb(26,188,156)"><div 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/<wbr>swift-evolution/blob/master/<wbr>proposals/0193-cross-module-<wbr>inlining-and-specialization.md</a></div></blockquote><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></div></blockquote><div>I am hugely supportive of the features that these attributes enable, but I think that the spelling of this is absolutely wrong, and I’m disappointed that the extensive discussion we’ve had for months about this didn’t make it into (at least) the alternatives considered section.  Here are my concerns:</div></div></div></blockquote><div><br></div></span><div>I’m totally aware of your earlier e-mail thread about tying this in with availability and I briefly mentioned it in the ‘future directions’ section. I don’t have any objections to your approach and I’d be open to changing the proposal if there’s some consensus that this is the right way to go.</div><div><br></div><div>Do you think exhaustive enums should be spelled as @available(exhaustive) (or @available(exhaustive: …)), also?</div><span class="gmail-"><br><blockquote type="cite"><div 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"><div>Furthermore, these two attributes are the tip of the iceberg, and the core team has spent a lot of time recently discussing the fact there are potentially going to be about a dozen attributes similar to these (fixed_contents,  global_var_is_directly_<wbr>addressible, …)  that will only be required for binary frameworks.</div></div></blockquote><div><br></div></span><div>Hopefully not a dozen! But yes, there will probably be more than just the three currently under discussion.</div><span class="gmail-"><br><blockquote type="cite"><div 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"><div>A minor point, but the specific name “abiPublic” is not great in my opinion, because “ABI” is a term of art for compiler hackers.  Most users have no idea what ABI means, and those who think they do often don’t.  Very few people really understand what “stable ABI” means for example.</div><div><br></div><div>It would be better to go with something like “apiPublic” or “symbolPublic” or “linkableButNotAccessible” or something else long.  This will not be commonly used in user code, so being long and descriptive is a good thing.</div></div></blockquote><div><br></div></span><div>Several other people in the thread also objected to the name abiPublic. I’m not attached to it and I would be open to changing it to something better. We just don’t have a clear winner yet...</div><span class="gmail-"><br><blockquote type="cite"><div 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"><div>which generalizes properly when we add version ranges:</div><div><div><br></div><div><span class="gmail-m_-7650217660453785746Apple-tab-span" style="white-space:pre-wrap">        </span>@available(iOS 14, *)   // this was introduced in iOS 14</div></div><div><span class="gmail-m_-7650217660453785746Apple-tab-span" style="white-space:pre-wrap">        </span>@available(linkerSymbol: iOS 15, *)  // this decl’s symbol became “abiPublic&quot; in iOS 15</div><div><span class="gmail-m_-7650217660453785746Apple-tab-span" style="white-space:pre-wrap">        </span>@available(inlinable: iOS 16, *)  // this decl became inlinable in iOS 16</div><div><span class="gmail-m_-7650217660453785746Apple-tab-span" style="white-space:pre-wrap">        </span>public func foo() {… }</div></div></blockquote><div><br></div></span><div>Minor nitpick: public implies ABI-public, so you probably meant the other way around, where a symbol became ABI public in iOS 14, then public in iOS 15. This is certainly something we need to support and my understanding is the equivalent already happens all the time in Objective-C land, where SPI becomes API.</div><span class="gmail-"><div><br></div><blockquote type="cite"><div 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"><div>In short, respectfully request that you at least add this approach to the &quot;alternatives considered” section.</div></div></blockquote><br></span></div><div>So, does anyone have any strong objections to Chris’s proposal?</div><div><br></div><div>From an implementation standpoint, reworking the parser to parse @available(inlinable) and @available(fixedContents) or whatever would be straightforward. I would still like to punt the version range part of this to a future proposal, though.</div><div><br></div></div></div></blockquote><div><br></div><div>I wish I had more time to compose a fully thought-out reply, but that&#39;s not going to happen in a little while because of outside constraints, so I&#39;ll spill a few thoughts here:</div><div><br></div><div>I&#39;m not a great fan of the @available(inlinable) notation.</div><div><br></div><div>For one, I have a hard time reasoning how Swift would behave when inlinability is tied to OS version. In this example, if the *app* (as opposed to the library) is compiled (as opposed to run) on iOS 16+, then the *library method* would potentially be emitted into the app, but if compiled on iOS 15 it wouldn&#39;t? Huh?</div><div><br></div><div>Second--and perhaps this is not a common opinion--I&#39;ve always thought that the @available notation was disastrous in terms of readability, especially when it comes to @available(unavailable) and the meaning of the asterisk. Every time, I have to run and look up whether it means the method is in fact available or unavailable for non-listed platforms. Again, with the understanding that this is not a fully formed thought, I have to say that I feel this is taking a readable and fairly straightforward concept (@inlinable) and adding on too many layers of baggage. That it was easy for Swift&#39;s creator to inadvertently invert the intended annotations in his initial example is, to me, a pretty good demonstration that the notation is not at all user-friendly.</div></div><br></div></div>