[Pitch] Adding accessibility specifiers to @available

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.

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

FYI

Excise "Accessibility" from the compiler:
<https://github.com/apple/swift/pull/11504>

···

On 22 Aug 2017, at 17:08, Tony Allevato wrote:

@jrose-apple (Jordan Rose) wrote:

"Accessibility" has a different meaning for app developers, so we've already deliberately excised it from our diagnostics in favor of terms like "access control" and "access level". Do the same in the compiler now that we aren't constantly pulling things into the release branch.

(This isn't exactly important, but we might as well clean it up.)

Whew! Thanks for the heads-up before my prototype hits merge-conflict
madness. :slight_smile:

···

On Tue, Aug 22, 2017 at 1:16 PM Ben Rimmington <me@benrimmington.com> wrote:

> On 22 Aug 2017, at 17:08, Tony Allevato wrote:
>
> 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. 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.

FYI

Excise "Accessibility" from the compiler:
<https://github.com/apple/swift/pull/11504>

> @jrose-apple (Jordan Rose) wrote:
>
> "Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms like
"access control" and "access level". Do the same in the compiler now that
we aren't constantly pulling things into the release branch.
>
> (This isn't exactly important, but we might as well clean it up.)