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

greenify <greeenify@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |greeenify@gmail.com

--- Comment #1 from greenify <greeenify@gmail.com> ---
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. Ideally Dscanner
(https://github.com/dlang-community/D-Scanner) should be able to yield such
warnings, but with it's current status as (a pure parser without any semantical
analysis) many of your warnings will be hard to achieve. Hence, I guess the
least controversial option is to introduce these warnings step by step with a
new opt-in flag in the D fronted.

--

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

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang@jmdavisProg.co
                   |                            |m

--- Comment #2 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
(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.

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 can certainly appreciate not wanting to compile your code twice (once to get your executable and once to be told about potential - but not definite - problems in your code), but IMHO, it really doesn't make sense for the compiler to be warning about optional things. And I've never seen it be anything but a disaster in practice with any other language. _Best_ case, you're stuck "fixing" all kinds of stuff that isn't actually wrong so that you don't have any warnings, 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.

> Ideally
> Dscanner (https://github.com/dlang-community/D-Scanner) should be able to
> yield such warnings, but with it's current status as (a pure parser without
> any semantical analysis) many of your warnings will be hard to achieve.
> Hence, I guess the least controversial option is to introduce these warnings
> step by step with a new opt-in flag in the D fronted.

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.

--

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

--- Comment #3 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
(In reply to Eyal from comment #0)
> * Signed/unsigned comparisons

There is talk of making this an error. I don't recall what's currently preventing it, but there is an open issue on the topic: issue #259

> * Code was determined to be dead (will never be executed)

Warinng about unreachable code is actually one of the few warnings that we actually do have.

--

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

--- Comment #4 from Eyal <eyal@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.

--

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

Eyal <eyal@weka.io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Add useful warnings         |Add optional errors/static
                   |                            |analysis

--

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

Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic

--

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

--- Comment #5 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
I would point out that optional errors would actually be extremely bad in D because of compile-time introspection. What code worked and compiled would change based on the compiler flags, effectively meaning that the language definition changed via the compiler flags. We already have problems with that thanks to -w (we really should just be made to do the same as -wi and then phase one of them out). To get the diagnostics that you're looking for without creating problems with compile-time introspection, there would need to be some sort of option that caused compilation to fail (as occurs with an error) when they occurred but which would be ignored for the purposes of compile-time introspection.

--

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

--- Comment #6 from Eyal <eyal@weka.io> ---
(In reply to Jonathan M Davis from comment #5)
> I would point out that optional errors would actually be extremely bad in D because of compile-time introspection. What code worked and compiled would change based on the compiler flags, effectively meaning that the language definition changed via the compiler flags. We already have problems with that thanks to -w (we really should just be made to do the same as -wi and then phase one of them out). To get the diagnostics that you're looking for without creating problems with compile-time introspection, there would need to be some sort of option that caused compilation to fail (as occurs with an error) when they occurred but which would be ignored for the purposes of compile-time introspection.

The introspection should always check whether it compiles with no optional errors enabled.

If the generated code does not compile because of the errors enabled, it should fail the build.

Because the optional errors are about likely error indicators, and introspection is about type checking / missing methods / etc.

It is fine, I believe, to fail a compilation due to optional errors, after including code that works without missing errors and was checked by __traits(compiles, ...).

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

--