Hello, Swift community.
The review of SE-0443: Precise Control Flags over Compiler Warnings ran from August 22nd through September 2nd, 2024.
There was a lot of great feedback in this review, and the Language Steering Group has been discussing the right path forward.
A lot of the feedback was about the proposed command line flag to suppress all warnings in particular groups. Many members of the community were dubious about this, saying that this was far too broad; what these developers would like is a more targeted ability to suppress warnings from specific locations in source, like the #pragma diagnostic feature in GCC and Clang. Some reviewers did speak up for it, though, especially as a way to gradually fix a new warning in a large codebase. In the end, the author chose to withdraw this part of the proposal during the review. The Language Steering Group thinks this is the right approach; suppression should be considered more holistically as part of a dedicated proposal that will build on the concept of diagnostic groups established here.
The review feedback on the overall feature that remains in SE-0443 — the ability to promote specific groups of warnings to be errors — was very positive.
There was some good discussion, both on and off the review thread, about how diagnostic groups ought to be defined. The most important question here is about the granularity of groups. Everyone seems to agree that there should be some groups that represent broad categories of warnings, such as all the concurrency-safety warnings (in language modes where these are not outright errors). Many users feel that it would be very helpful for there to also be very narrow groups, perhaps to the level of every individual diagnostic template (a concept in the primary compiler implementation) being in its own group so that it can always be specifically controlled.
The Language Steering Group has chosen to not make the development of specific diagnostic groups subject to the evolution process. Therefore, drawing the exact boundaries of groups will be up to compiler contributors. The LSG encourages those developers to consider the feedback above when making those decisions. Furthermore, while there is no proactive process that needs to be followed to add new groups, the LSG invites compiler developers to discuss diagnostics (or at least link PRs that add diagnostics) in a dedicated thread in Development > Compiler that interested users can easily follow and provide feedback on.
The LSG is satisfied with the proposal as it currently stands, and accordingly SE-0443 is accepted.
I'd like to thank the community once again for its valuable feedback on this proposal.
John McCall
Review Manager