> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu <xiaodi...@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() {

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.


swift-evolution mailing list

Reply via email to