> On Dec 21, 2017, at 11:08 PM, Slava Pestov <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
