<div dir="ltr">On Fri, Dec 22, 2017 at 6:12 PM, Chris Lattner <span dir="ltr">&lt;<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Dec 22, 2017, at 1:03 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="m_-2751741850073723399Apple-interchange-newline"><div><div class="m_-2751741850073723399Singleton"><div dir="ltr"><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"><div><div><span class="m_-2751741850073723399gmail-"><blockquote type="cite" 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 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 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"></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></div></div></div></div></blockquote><div><br></div></span>No rush, no worries, enjoy the holiday!</div><div><span class=""><br><blockquote type="cite"><div><div class="m_-2751741850073723399Singleton"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></div></div></blockquote><div><br></div></span><div>No: availability information kicks in based on what you are *deploying* to, not what you’re compiling on.</div><div><br></div><div>I expect that this stuff will be extremely rarely used in practice, but here’s an example:</div><div><br></div><div>iOS15 declares this public:</div><div><br></div><div>public void foo() {</div><div>   bar()</div><div>}</div><div><br></div><div>iOS16 wants to promote foo to inlinable, but knows that the inlined body doesn’t work with iOS15, because iOS15 needs the call to bar to happen (for whatever reason)</div><div><br></div><div>@available(inlinable: iOS16)</div><div>public void foo() {</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>// nothing needed on iOS16 or later.</div></div></blockquote><div><div>}</div></div></div></blockquote><div><br></div><div>Deployment platform makes more sense, but I still can&#39;t envision a real use case. What sorts of `bar()` would hypothetically be necessary for iOS 15 but not 16? Why would a third-party library need to increase its inlining availability for an app based on deployment platform?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>The vastly most common case is that something is defined as inlinable and always inlinable, that’s why the @available(inlinable) form is important, and why it may make sense to further sugar that default case to @inlinable.</div><span class=""><div><br></div><br><blockquote type="cite"><div><div class="m_-2751741850073723399Singleton"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></div></div></blockquote></span></div><div><br></div><div>I agree that @available(unavailable) is a mess, this direction doesn’t make it worse though.</div><div><br></div><div>However, the thing I inverted wasn’t the syntax, it was the “abipublic” example.  abipublic is a confusing concept no matter how it is spelled.</div></div></blockquote><div><br></div><div>I understand. I was writing about the &quot;abiPublic&quot; example as well, and I mentioned @available(unavailable) for precisely that reason:</div><div><br></div><div>The mess inherent to @available(unavailable) doesn&#39;t stem purely from inelegance in spelling. Rather, @available(anything) looks as though the &quot;anything&quot; should be a particular kind of API availability, but @available(unavailable) is _not_ a kind of API availability but precisely the opposite: unavailability.</div><div><br></div><div>I&#39;m quite sure that the reason you inverted your &quot;abiPublic&quot; example is because of the same issue. Intuitively, you would want to mark something as &quot;available&quot; in version N and then maybe some special kind of &quot;available&quot; in version N+1 (which @available(inlinable) would be). But @available(linkerSymbol), as you spell it, suffers from a similar problem to that of @available(unavailable): it&#39;s _not_ a special kind of API availability, but rather indicates that something is less-than-available. That is, you would use it to indicate that something is available as ABI but not as API. In that sense, it extends the &quot;mess&quot; we have with @available(unavailable).</div></div></div></div>