On Dec 22, 2017, at 9:12 PM, Slava Pestov <spes...@apple.com> wrote: >> 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? > > A better example would be if bar() was itself only available in iOS 16: > > @available(iOS 15) > @available(inlinable: iOS 16) > public func foo() { > bar() > } > > @available(iOS 16) > public func bar() { … } > > 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().
Thanks, that’s a much better example. >> 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). > > 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. Right. The bug here is with @available(unavailable). Its design is clearly broken and oxymoronic. That doesn’t make all of @available broken. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution