> 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. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
