Sorry to ask such a basic question, but is there a way currently to disable warning for dependencies (I'm using SPM). Currently, this leads to me ignoring warnings altogether because there's just so many of them.
Nope there isn't, and this is the problem 
1 Like
There's a difference between "disabling warnings for dependencies" and "disabling warnings for the use of dependencies". That's reasonable (though perhaps not the most secure idea), and separate from what we're discussing here. I suggest spinning off a different thread for that, since that'd be a SwiftPM feature.
We just found another case where being able to treat warnings as errors except deprecations would be very useful to us. We deprecated one API in our framework and we had to turn off completely the -warnings-as-errors in the test target since we want to keep the unit tests for the deprecated API: https://github.com/spotify/Mobius.swift/pull/28#issuecomment-496186437
Is there anything that would make it easier (or convince the Core team) to add such a feature in a future Swift release?
1 Like
I’ve encountered the same issue described by Patrick. The particular case of testing an otherwise deprecated api has made me wish for a way to silence a specific deprecation warning.
For the unit test problem, perhaps deprecation warnings could be automatically silenced when using declarations from a @testable import.
1 Like
Apologies if zombifying this thread is against policy, I can also start a new thread if desired.
Swift's lack of being able to ignore deprecations has made it such that we cannot enable warnings-as-errors and thus got up to over 400 warnings, meaning people miss new warnings all of the time.
It has become one of those "it's always yellow, ignore it" things with three figure number of engineers.
Deprecations are a big problem because we deprecate our own APIs, or for example right now, we are updating to a new Xcode major version and cannot fix all deprecations for all teams in a timely fashion and test and qualify the work. It just does not work at scale.
What I would love is for deprecations to be treated as something different than warnings, and even shown separately in the UI, with UI so people know to not ignore it. We can open SLA tickets for major issues that should be addressed, but warnings-as-errors would keep the basic code base in better shape with zero noise so any time a new warning did appear, the engineer woule have to address it.
As soon as I bump the deployment version, a wave of deprecations come in, and I would have to disable warnings-as-errors to even build and see if we can get CI going.
Thank you for your time!
1 Like
It's probably best to start a new thread if you want to discuss this topic in depth. A more recent conversation about a solution to this problem happened in [Pitch] Attribute to silence Deprecation Warnings for a specified scope.
1 Like