> On Dec 23, 2017, at 2:59 PM, Chris Lattner <clatt...@nondot.org> wrote:
>>> I'm quite sure that the reason you inverted your "abiPublic" example is 
>>> because of the same issue. Intuitively, you would want to mark something as 
>>> "available" in version N and then maybe some special kind of "available" in 
>>> version N+1 (which @available(inlinable) would be). But 
>>> @available(linkerSymbol), as you spell it, suffers from a similar problem 
>>> to that of @available(unavailable): it's _not_ a special kind of API 
>>> availability, but rather indicates that something is less-than-available. 
>>> That is, you would use it to indicate that something is available as ABI 
>>> but not as API. In that sense, it extends the "mess" we have with 
>>> @available(unavailable).
>> I don’t think it’s quite the same thing as @available(unavailable). An 
>> @available(abiPublic) symbol would still be declared to have internal 
>> visibility, so in this case the @available attribute makes it strictly more 
>> visible than it would be without. We’re not going to spell it as 
>> ‘@available(abiPublic) public’, which indeed would be confusing because the 
>> symbol is not actually public at the source level.
> Right.  The bug here is with @available(unavailable).  Its design is clearly 
> broken and oxymoronic.  That doesn’t make all of @available broken.

Random thought: I think this all would make more sense if we rename @available 
-> @availability and unavailable -> removed.


swift-evolution mailing list

Reply via email to