[swift-evolution] [Pitch] Adding accessibility specifiers to @available

[Tony Allevato]

Hi all,

A few months ago (before Swift 5 chatter started), I pitched an idea to
improve the use of @availability in third-party code by eliminating
deprecation warnings in same-file references
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036452.html>.
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.

More recently, another contributor had a similar idea for unavailable
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170703/037959.html>
that I unfortunately missed when it was posted.

So, I've jotted down my ideas to add accessibility specifiers to @available
in an early draft here
<https://gist.github.com/allevato/76f098a761147f3be5017d10a6f4ecbb> and
started an implementation
<https://github.com/allevato/swift/compare/master...allevato:deprecation-levels>.
(The syntax is just one possibility; the one presented here was easy to
implement.)

Some of the key points:

* Library authors often need to make something deprecated/unavailable
externally while still permitting its use internally (or lower, like at the
file level).

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

* IMO, accessibility-based diagnostics attached to the declaration
(library-author-controlled) are better than diagnostic-suppression blocks
(client-controlled, e.g. @SuppressWarnings("deprecation") 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.

Some of the ideas I've written up seem to be closely related to Jordan Rose
and John McCall's library evolution
<https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst>
document—I'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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170822/24c7aa0e/attachment.html>