Hello, Swift community!
The review of SE-0522: Source-Level Control Over Compiler Warnings ended on April 2, 2026.
Feedback on the proposal was generally positive, with many commenters agreeing that having the ability to fine-tune warning control within the scope of specific declarations was a good first step toward solving a real problem in the language.
There was a significant amount of early feedback about the name of the attribute. Many commenters felt that readings such as @warn(WarningGroupName, as: error) would be confusing. Based on some naming suggestions in the thread, the author agreed that a better spelling for the attribute would be @diagnose, and the Language Steering Group agrees with this choice.
Some commenters raised questions about how this feature would interact with code that emits warnings from a new diagnostic group on a newer compiler while still wanting to support compiling with older toolchains. As proposed, the feature emits a warning if the warning group is unrecognized by the compiler, and this is consistent with the behavior of the command line flags for warning control. This means that conditional logic, like #if compiler(>=X.Y), must be used to wrap the attribute. The Language Steering Group feels that this is the correct trade-off. An alternative, like silently ignoring unrecognized warning groups, would be more harmful since it removes the ability to detect when the user has made a legitimate spelling mistake in their code.
There was also discussion about whether the proposed attribute should be discouraged for deprecation warnings. The Language Steering Group feels that there is still room for improvement in that space but that it does not have to come at the expense of this feature. While a @diagnose attribute on individual declarations may not be the best fit for all kinds of deprecations (e.g., code that makes significant use of deprecated APIs from a framework for which there are no usable alternatives), the proposed feature still gives users some mechanism by which to address them.
For these reasons, the Language Steering Group accepts this proposal.
Thanks to everybody who participated in the review!
—Tony Allevato, review manager