[swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

Chris Lattner clattner at nondot.org
Sat Dec 23 16:59:17 CST 2017


On Dec 22, 2017, at 9:12 PM, Slava Pestov <spestov at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171223/df62cea3/attachment.html>


More information about the swift-evolution mailing list