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

[Xiaodi Wu]

On Fri, Dec 22, 2017 at 6:12 PM, Chris Lattner <clattner at nondot.org> wrote:

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

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?

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

I understand. I was writing about the "abiPublic" example as well, and I
mentioned @available(unavailable) for precisely that reason:

The mess inherent to @available(unavailable) doesn't stem purely from
inelegance in spelling. Rather, @available(anything) looks as though the
"anything" should be a particular kind of API availability, but
@available(unavailable) is _not_ a kind of API availability but precisely
the opposite: unavailability.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171222/05a24314/attachment.html>