<div dir="ltr">Hi all,<div><br></div><div>A few months ago (before Swift 5 chatter started), I pitched an idea to improve the use of @availability in third-party code by <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036452.html">eliminating deprecation warnings in same-file references</a>. We had some good discussion there about who needed same-file deprecation vs. same-module deprecation and so forth, and I was convinced that a better approach would be to allow @available to be enforced based on accessibility.</div><div><br></div><div>More recently, another contributor had a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170703/037959.html">similar idea for unavailable</a> that I unfortunately missed when it was posted.</div><div><br></div><div>So, I&#39;ve jotted down my ideas to add accessibility specifiers to @available in an <a href="https://gist.github.com/allevato/76f098a761147f3be5017d10a6f4ecbb">early draft here</a> and started an <a href="https://github.com/allevato/swift/compare/master...allevato:deprecation-levels">implementation</a>. (The syntax is just one possibility; the one presented here was easy to implement.)</div><div><br></div><div>Some of the key points:</div><div><br></div><div>* Library authors often need to make something deprecated/unavailable externally while still permitting its use internally (or lower, like at the file level).</div><div><br></div><div>* It is not possible to do so today without the compiler emitting diagnostics. Thus, libraries/frameworks that are evolving are littered with build noise that make those libraries appear to be poorly maintained.</div><div><br></div><div>* IMO, accessibility-based diagnostics attached to the declaration (library-author-controlled) are better than diagnostic-suppression blocks (client-controlled, e.g. @SuppressWarnings(&quot;deprecation&quot;) in Java) because the latter hides important information that the library author is trying to communicate. However, this proposal does not preclude the addition of something like that either.</div><div><br></div><div>Some of the ideas I&#39;ve written up seem to be closely related to Jordan Rose and John McCall&#39;s <a href="https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst">library evolution</a> document—I&#39;d be particularly interested in their thoughts about whether the ideas they present there collide/conflict with this idea, or if they would work well together.</div><div><br></div></div>