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

[Chris Lattner]

> On Dec 21, 2017, at 11:08 PM, Slava Pestov <spestov at apple.com> wrote:
>> 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?

When and if we add private cases to enums, we’ll need to be able to associate an availability range with an “exhaustive” marker.  When/if that happens, then yes, we should do so through @available(exhaustive: iOS41, *).    The @exhaustive attribute will become sugar for “born exhaustive”, because in the absence of private cases the availability range doesn’t matter (AFAIK).

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

This is the sort of thing that will creep over the years: lots of sorts of people care about performance, and different sorts of people have different requirements.  Specific narrow features can have a huge impact on specific cases, and we should support those needs.

Look at how many obscure attributes GCC has accreted and what a mess it is, we don’t want Swift to look like that in 15 years.

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

You’re right, I got the order backward.  The point stands though :-)

> 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 agree.  I’m only concerned that we have a direction that supports the availability ranges in a coherent way, I don’t see any urgency to actually implement them today.

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171222/19659a43/attachment.html>