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

[Chris Lattner]

> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
>> In short, respectfully request that you at least add this approach to the "alternatives considered” section.
> 
> So, does anyone have any strong objections to Chris’s proposal?
> 
> 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.
> 
> 
> 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:

No rush, no worries, enjoy the holiday!

> I'm not a great fan of the @available(inlinable) notation.
> 
> 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?

No: availability information kicks in based on what you are *deploying* to, not what you’re compiling on.

I expect that this stuff will be extremely rarely used in practice, but here’s an example:

iOS15 declares this public:

public void foo() {
   bar()
}

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)

@available(inlinable: iOS16)
public void foo() {
// nothing needed on iOS16 or later.
}


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.


> 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.


I agree that @available(unavailable) is a mess, this direction doesn’t make it worse though.

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.

-Chris



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