On Wednesday, 26 September 2018 at 09:25:11 UTC, Jonathan M Davis
wrote:
It's just a message. You can use a compiler flag to make the
message go away or to turn it into an error (though in general,
I'd advise against it, since then your code breaks as soon as
something gets deprecated), but by default, they're just
messages.
That's precisely what warnings are: messages that can be silenced
or turned into errors. When people talk about warnings, that's
usually what they mean.
Personally speaking, I like to treat warnings as problems that
don't stop your code from compiling during development (eg I
don't want to worry about my extranous return statements when I'm
doing quick experiments), but can't be accepted upstream, and
have to trigger errors in CI.
But with a robust warning system, other approaches are possible.
Unfortunately, if your build spits out a bunch of status stuff
instead of just printing out actual problems, deprecation
messages do sometimes get missed
Warnings often catch real problems, even categories of warnings
with high amounts of false positives like unused variables.
But yeah, I get your point. Warning lose their interest when they
start to pile up in your codebase to the point it's impossible to
notice new ones, and it's impossible to turn them into errors
because there's already too many.
That said, that's a problem with D compilers, not with the
concept of warnings. You mention that deprecations warnings are
nice because they can be turned off; ideally, all categories of
warnings should be like that.
What DMD and GDC lack (I think) is GCC's level of granularity,
with flags like
-Wnonnull
-Werror=missing-attributes
-Wno-error=misleading-indentation
But that doesn't mean the concept of compiler warnings needs to
be thrown away.
