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

[Slava Pestov]

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

Slava

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171221/96eaf1bd/attachment.html>