<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="">On Dec 22, 2017, at 9:12 PM, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:<br class=""><div><blockquote type="cite" 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; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" 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;"><div class="gmail_extra"><div class="gmail_quote"><div class="">Deployment platform makes more sense, but I still can'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></div></div></div></blockquote><div class=""><br class=""></div><div class="">A better example would be if bar() was itself only available in iOS 16:</div><div class=""><br class=""></div><div class="">@available(iOS 15)</div><div class="">@available(inlinable: iOS 16)</div><div class="">public func foo() {</div><div class=""> bar()</div><div class="">}</div><div class=""><br class=""></div><div class="">@available(iOS 16)</div><div class="">public func bar() { … }</div><div class=""><br class=""></div><div class="">Suppose your app calls foo() and deploys to iOS 15. Then you cannot inline foo(), because bar() does not exist on iOS 15. (Presumably, foo() had a different implementation on iOS 15). But if you’re deploying to iOS 16, all is well, and you can inline foo(), which results in your app directly calling bar().</div></div></blockquote><div><br class=""></div><div>Thanks, that’s a much better example.</div><br class=""><blockquote type="cite" 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; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div dir="ltr" class="" 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;"><div class="gmail_extra"><div class="gmail_quote"><div class="">I'm quite sure that the reason you inverted your "abiPublic" example is because of the same issue. Intuitively, you would want to mark something as "available" in version N and then maybe some special kind of "available" 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'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 "mess" we have with @available(unavailable).</div></div></div></div></blockquote><br class=""></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; -webkit-text-stroke-width: 0px;" class="">I don’t think it’s quite the same thing as @available(unavailable). An @available(abiPublic) symbol would still be declared to have internal visibility, so in this case the @available attribute makes it strictly more visible than it would be without. We’re not going to spell it as ‘@available(abiPublic) public’, which indeed would be confusing because the symbol is not actually public at the source level.</div></blockquote><br class=""></div><div>Right. The bug here is with @available(unavailable). Its design is clearly broken and oxymoronic. That doesn’t make all of @available broken.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>