[swift-dev] Categorization of warnings in Swift
kremenek at apple.com
Wed Jan 20 00:21:56 CST 2016
> On Jan 13, 2016, at 4:51 PM, Michael Ilseman via swift-dev <swift-dev at swift.org> wrote:
> As far as front-end options, any preferences on the command-line switches? I don’t see a need to keep consistency with GCC/Clang here, so perhaps “-suppress-warnings” and “-warnings-as-errors”?
There may not be a need for consistency, but there may be value in being consistent.
If you go with a cohesive model where there are warning categories and separate categories can be enabled, disabled, promoted to errors, etc., then there are merits to GCC/Clang's warning style that I don't think should just be dismissed out of hand. Deviating can provide negative value because it a different scheme that is, well, just different, but conceptually similar to something many developers already know.
Before dismissing -Werror and -w, consider the taxonomy that they are a part of in the GCC/Clang world:
This is a very general scheme for controlling warnings. Perhaps "-w" and "-Werror" are a bit special case, so you could always do something like:
And just have a warning category for "all warnings".
If you are going to go down the route of having any control for warnings from the command line --- which I realize is a contentious topic on this thread --- I personally believe that the flags should be simple, consistent, and generalized. Having special case flags like "-suppress-warnings" and "-warnings-as-errors" feels more even more special case, and I just have to know what they are.
I'm not married to the -W flags scheme, but it is something that is understood. If we are going to have flags, I'd prefer something that was equally (or more) understandable with a general and simple scheme for controlling warnings.
More information about the swift-dev