> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
