[Issue 17424] Add useful warnings

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17424

--- Comment #4 from Eyal <eyal at weka.io> ---
(In reply to Jonathan M Davis from comment #2)
> (In reply to greenify from comment #1)
> > Great idea. This is one of the areas where D is definitely behind other
> > languages.
> > IIRC Walter believes that the compiler isn't a linter, so if I am not
> > mistaken only warnings with minimal or zero overhead will be merged.
> 
> His take on it is that warnings are a sign that folks couldn't agree on what
> was right or wrong in the language. He tends to think that something should
> either be an error or not (and I agree with him). But the issue of warnings
> has been discussed many times in the newsgroup, and I really don't think
> that many are going to be added to the compiler. And the fact that dmd
> stupidly has -w makes them that much worse because of how that affects
> compile-time introspection.

And folks indeed can't agree, and for good reason! Different people assign
different importance to correctness vs. convenience.

I agree that "warnings" should always actually be errors (-Werror) - but we
will never reach consensus on what the set of warnings should actually be. And
of course, they shouldn't affect __traits(compiles, ...) and is(typeof(..)).

If someone uses D for small <3-5KLOC projects, where a build-test-debug-cycle
is 10 seconds and a bug is a minor nuisance, of course he wants convenience.
Emphasis on correctness is not worth the hassle.

We use D for a large project, with a much much slower build-test-debug-cycle.
Bugs easily cost us hours. Detected late, they can cost us days. Undetected,
they can be disastrous.

Our trade-offs are different, so there is no one-size-fits-all. And this is why
a language that wants to cater to both of these audiences should have flags.

> Ultimately though, the big problem with warnings is that if you're doing
> your job right, you fix them all (if you don't, you just end up with a big
> pile of warnings that get ignored and so you miss whatever value they do
> provide), and so you might as well either make them errors or not warn about
> them at all. And it gets _very_ annoying when the compiler warns about
> something that shouldn't need to be changed. Really, anything that's going
> to be optional makes far more sense in a linter.

I don't want multiple tools to spend time CTFE'ing my code and increase an
already long debug cycle.

Perhaps reframing the discussion from "warnings" to "optional errors" is
better.

> _Best_ case,
> you're stuck "fixing" all kinds of stuff that isn't actually wrong so that
> you don't have any warnings, 

This is the case for me everywhere I had the ability to set the warnings policy
(-W<kitchen sink> -Werror). This is a *cheap* price to pay, compared to a
single unexpected week lost to a completely unnecessary bug.

> but more often, you end up with tons of
> warnings that no one pays attention to. Having at tool that can warn about
> potential problems has real value, but I don't think that it's appropriate
> for the compiler to be doing it.

Agreed. That's why "optional errors" is how I should have framed it, and not
"warnings".

> Walter is also very much against additional compiler flags. So, I think that
> you're going to have a hard time convincing him that this is a good idea.
> Having the compiler as a library as has been discussed would make it easier
> to write a linter, but based on past discussions on this topic, I think that
> it's pretty clear that the vast majority of these suggestions will never be
> compiler warnings even if they make a lot of good sense for a linter.

One-size fits all is going to be bad for one group or the other. Compiler flags
are bad for the compiler's manpage.

--