Welcome to the community @lordzsolt. You raise a valid concern. I concur with @Rod_Brown that while reporting a bug is important, it is not very helpful. That must be really frustrating to always see the one warning.
You forgot the fourth and fifth options
- Move the code into a simple module that is compiled with deprecation warning turned off and imported by your main module.
- Move this code into an objc file.
3 Likes
This is a concern for us with Swift 5.5 / async. We will effectively be deprecating large numbers of completion-blocks APIs, because we want to discourage new uses of them in favor of new async versions. However, doing so will create a bajillion "use of deprecated API" warning in every file immediately.
Ideally we want to grandfather in existing uses and warn on new ones. A callside mechanism to suppress the deprecation warning would be sufficient for this purpose.
1 Like
I think this pitch is trying to handle this case: only warn about use of the ‘old’ completion handler API if it’s being called from an async context, where the async alternative would be preferred.
The problem with this is that it loses the opportunity to give us hints about contexts that should be async but aren’t. Doing this would either require an opt-in to always show the warnings, or a separate tool that does all the analysis redundantly.
(See also: Auditing potentially async code)
This, like deprecation warnings, seems like a case where judicious use of optional warnings (and selective -Werror) would be to everyone’s benefit.
1 Like
+1 for any solution that gives me a command line switch to disable all suppressions so I can quickly get a list of all potential code problems regardless of wether the associated warning has been suppressed.
This hit me again today: due to some implementation and specification changes, it has become awkward to support an existing API and the best thing to do is deprecate it. I've managed to back-port it (at a significant performance cost) to support anybody who might be using it, but I intend to remove it in the near future.
The problem is: I can't test the back-porting code without adding a bunch of warnings all over my tests.
It's fine, I can take that, but I'd rather not. It's messy and obscures actual warnings that might be alerting me to issues with my test code.
4 Likes
If you're using XCTest, you can test deprecated APIs by marking the test method or class as deprecated itself. Deprecated code is allowed to call other deprecated code, so this will suppress the diagnostics on the calls you're making, but XCTest invokes your test cases without physically writing those names in source code, so it won't raise any new deprecations.
27 Likes