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.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
