[swift-dev] Categorization of warnings in Swift

[Ted kremenek]

> 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:

  -Werror-<warning>
  -Wno-error-<warning>
  -Wno-<warning>

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:

  -Wno-all
  -Werror-all

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.