[swift-dev] Categorization of warnings in Swift

Ted kremenek 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 mailing list