This problem is actually two similar but still separate problems:
- How to handle declaration and use of deprecated APIs that you control
- How to handle use of deprecated APIs that you don't control
The first issue, which @Keith covers, is one that affects us in swift-protobuf as well, because the protocol buffer spec lets users declare fields as deprecated and we want to reflect that as a deprecation in the generated Swift code as well. But because the field must still be referenced in the generated code (the corresponding property must be touched to read or write the message), it generates unavoidable* warnings. (*without generating much nastier code, like distinguishing the backing storage of the field from the public property)
For that use case, a while back I pitched suppressing deprecation warnings within the same file, which was enough for my use case but not for some others, so the discussion refined it to the idea of attaching an access level to the deprecation that determines where warnings are emitted. I'd like to find the time to revive this, so I'm glad someone brought the topic up again. I have a partial implementation lying around somewhere and it didn't seem too complicated.
For the case of deprecated APIs you don't control, like system APIs, I'm not convinced that we should allow them to be suppressed. Deprecated APIs are deprecated for a reason and shouldn't be relied on; the warning is a constant reminder that the API could disappear or stop functioning correctly later. Developers absolutely should be allocating time for the unglamorous task of migrating when they bump the SDK version, and I see the warnings as an important feature in that regard. Once suppressed, they run the risk of being forgotten, potentially causing more pain later.
Ultimately, I think deprecation should still be left entirely in the hands of the API authors, but we should expand the controls they're given to make it less of an all-or-nothing proposition.