<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 22, 2017, at 1:03 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="Singleton"><div dir="ltr" class=""><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;" class=""><div class=""><div class=""><span class="gmail-"><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><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;" class=""><div class="">In short, respectfully request that you at least add this approach to the "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; -webkit-text-stroke-width: 0px;" class=""></span></div><div class="">So, does anyone have any strong objections to Chris’s proposal?</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">I wish I had more time to compose a fully thought-out reply, but that's not going to happen in a little while because of outside constraints, so I'll spill a few thoughts here:</div></div></div></div></div></div></blockquote><div><br class=""></div>No rush, no worries, enjoy the holiday!</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="Singleton"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">I'm not a great fan of the @available(inlinable) notation.</div><div class=""><br class=""></div><div class="">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't? Huh?</div></div></div></div></div></div></blockquote><div><br class=""></div><div>No: availability information kicks in based on what you are *deploying* to, not what you’re compiling on.</div><div><br class=""></div><div>I expect that this stuff will be extremely rarely used in practice, but here’s an example:</div><div><br class=""></div><div>iOS15 declares this public:</div><div><br class=""></div><div>public void foo() {</div><div> bar()</div><div>}</div><div><br class=""></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 class=""></div><div>@available(inlinable: iOS16)</div><div>public void foo() {</div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div>// nothing needed on iOS16 or later.</div></div></blockquote><div><div>}</div><div><br class=""></div><div><br class=""></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><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="Singleton"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Second--and perhaps this is not a common opinion--I'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'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></div><div class=""><br class=""></div><div class="">I agree that @available(unavailable) is a mess, this direction doesn’t make it worse though.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>