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

[Xiaodi Wu]

On Fri, Dec 22, 2017 at 2:08 AM, Slava Pestov via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi Chris,
>
> Thanks for reviewing the proposal!
>
> On Dec 20, 2017, at 11:14 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Dec 20, 2017, at 4:19 PM, Ted Kremenek <kremenek at apple.com> wrote:
>
> The review of "SE-0193 - Cross-module inlining and specialization" begins
> now and runs through *January 5, 2018*.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0193-cross-module-inlining-and-specialization.md
>
> When reviewing a proposal, here are some questions to consider:
>
>    -
>
>    What is your evaluation of the proposal?
>
> I am hugely supportive of the features that these attributes enable, but I
> think that the spelling of this is absolutely wrong, and I’m disappointed
> that the extensive discussion we’ve had for months about this didn’t make
> it into (at least) the alternatives considered section.  Here are my
> concerns:
>
>
> I’m totally aware of your earlier e-mail thread about tying this in with
> availability and I briefly mentioned it in the ‘future directions’ section.
> I don’t have any objections to your approach and I’d be open to changing
> the proposal if there’s some consensus that this is the right way to go.
>
> Do you think exhaustive enums should be spelled as @available(exhaustive)
> (or @available(exhaustive: …)), also?
>
> Furthermore, these two attributes are the tip of the iceberg, and the core
> team has spent a lot of time recently discussing the fact there are
> potentially going to be about a dozen attributes similar to these
> (fixed_contents,  global_var_is_directly_addressible, …)  that will only
> be required for binary frameworks.
>
>
> Hopefully not a dozen! But yes, there will probably be more than just the
> three currently under discussion.
>
> A minor point, but the specific name “abiPublic” is not great in my
> opinion, because “ABI” is a term of art for compiler hackers.  Most users
> have no idea what ABI means, and those who think they do often don’t.  Very
> few people really understand what “stable ABI” means for example.
>
> It would be better to go with something like “apiPublic” or “symbolPublic”
> or “linkableButNotAccessible” or something else long.  This will not be
> commonly used in user code, so being long and descriptive is a good thing.
>
>
> Several other people in the thread also objected to the name abiPublic.
> I’m not attached to it and I would be open to changing it to something
> better. We just don’t have a clear winner yet...
>
> which generalizes properly when we add version ranges:
>
> @available(iOS 14, *)   // this was introduced in iOS 14
> @available(linkerSymbol: iOS 15, *)  // this decl’s symbol became
> “abiPublic" in iOS 15
> @available(inlinable: iOS 16, *)  // this decl became inlinable in iOS 16
> public func foo() {… }
>
>
> Minor nitpick: public implies ABI-public, so you probably meant the other
> way around, where a symbol became ABI public in iOS 14, then public in iOS
> 15. This is certainly something we need to support and my understanding is
> the equivalent already happens all the time in Objective-C land, where SPI
> becomes API.
>
> 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:

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?

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