On Fri, Dec 22, 2017 at 2:08 AM, Slava Pestov via swift-evolution < swift-evolution@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@swift.org> wrote: > > On Dec 20, 2017, at 4:19 PM, Ted Kremenek <kreme...@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
