They are discussing about having -Wall on default in GCC 4.8:

http://gcc.gnu.org/ml/gcc/2012-04/msg00087.html
http://gcc.gnu.org/ml/gcc/2012-04/threads.html#00092

In D.learn I've seen plenty of people not use -wi (or -w) in D programming, and this has caused some troubles.

So what do you think about having "-wi" (and even -property too) on default in D (and have a compiler switch to disable warnings on request)?

Bye,
bearophile

On 08-05-2012 01:25, bearophile wrote:
> They are discussing about having -Wall on default in GCC 4.8:
>
> http://gcc.gnu.org/ml/gcc/2012-04/msg00087.html
> http://gcc.gnu.org/ml/gcc/2012-04/threads.html#00092
>
> In D.learn I've seen plenty of people not use -wi (or -w) in D
> programming, and this has caused some troubles.
>
> So what do you think about having "-wi" (and even -property too) on
> default in D (and have a compiler switch to disable warnings on request)?
>
> Bye,
> bearophile

We should strive to avoid warnings at all. Usually (though not always) something that is a warning should really be an error.

That said, I think turning these on by default is a very good idea.

I think individual options to turn specific warnings off will complicate things too much. What I think we should do is make -wi the default and make an option that is just the inverse. I think that will suffice for most real use cases (I mean, we're D, not C; we don't have over 9000 warning variants).

-- 
- Alex

On May 7, 2012 7:33 PM, "Alex Rønne Petersen" <xtzgzorex@gmail.com> wrote:
>  (I mean, we're D, not C; we don't have over 9000 warning variants).
>
> --
> - Alex

Yet.

Alex Rønne Petersen:

> I think individual options to turn specific warnings off will complicate things too much. What I think we should do is make -wi the default and make an option that is just the inverse.

Right, that's what I meant, a single switch to disable all warnings.

Bye,
bearophile

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:rxwrviokohajqsmkbotd@forum.dlang.org...
> They are discussing about having -Wall on default in GCC 4.8:
>
> http://gcc.gnu.org/ml/gcc/2012-04/msg00087.html http://gcc.gnu.org/ml/gcc/2012-04/threads.html#00092
>
> In D.learn I've seen plenty of people not use -wi (or -w) in D programming, and this has caused some troubles.
>
> So what do you think about having "-wi" (and even -property too) on default in D (and have a compiler switch to disable warnings on request)?

I'm all for it, but (for DMD) I don't think Walter will ever go for it. Just getting him to cave and allow the -wi switch in the first place took a *lot* of nagging ;) (I'm still *very* thankful -wi did get put in, though!)

On Tuesday, May 08, 2012 01:25:54 bearophile wrote:
> They are discussing about having -Wall on default in GCC 4.8:
> 
> http://gcc.gnu.org/ml/gcc/2012-04/msg00087.html http://gcc.gnu.org/ml/gcc/2012-04/threads.html#00092
> 
> In D.learn I've seen plenty of people not use -wi (or -w) in D programming, and this has caused some troubles.
> 
> So what do you think about having "-wi" (and even -property too)
> on default in D (and have a compiler switch to disable warnings
> on request)?

The funny thing is that what -wi does is how every other compiler I've ever used operates. Warnings are always on and never stop compilation. Additional flags may add new warnings, and others may be used to silence certain warnings, but dmd's default of _no_ warnings is very odd. And -w is _completely_ unique AFAIK. The idea of basically _adding errors_ is a bit odd. So, from the standpoint of how compilers typically work, Walter's choices are definitely odd.

That said, I increasingly agree with Walter's philosophy that something should either be an error or not and that warnings are flawed by nature. A good programmer will never leave _any_ warnings in committed code. So, nothing which is a warning is really any different from an error except for the fact that it may be reasonable to leave it alone temporarily while editing or debugging code. And as such, having warnings becomes seriously suspect in the first place - _especially_ when a warning isn't something that a programmer would necessarily agree needs to be fixed. They ultimately lead to bad programmers leaving them in, making it difficult to see new ones or see what's wrong in general, and it can be a royal pain to go and spend the time to clean up all of the existing warnings (I've done it in real world projects in Java and C++; I hate it).

So, I'd actually be tempted to argue for making -w the default, and ditching - w and -wi entirely. And Walter's probably more likely to go for that then making -wi the default.

But certainly the normal thing to do would be to make -wi the default. It'll never happen, but it would be how most compilers work.

- Jonathan M Davis

Jonathan M Davis:

> A good programmer will never leave _any_ warnings in committed code.

Sometimes warnings are wrong, the compiler is not perfect.
If the compiler is certain there is a mistake in the code, then generating an error is better. Bugs are probabilistic.
Good lints don't have just "errors", they report issues classified in four or five levels of increasingly probability of actual problem being present (naming them something like "Info", "Note", "Warning", "Probable Error", and "Error").


> But certainly the normal thing to do would be to make -wi the default. It'll never happen, but it would be how most compilers work.

Thank you Jonathan for the very nice way you kill this idea ;-) I have some faith in future improvements still.

Bye,
bearophile

On Tuesday, May 08, 2012 04:21:06 bearophile wrote:
> Jonathan M Davis:
> > A good programmer will never leave _any_ warnings in committed code.
> 
> Sometimes warnings are wrong, the compiler is not perfect.
> If the compiler is certain there is a mistake in the code, then
> generating an error is better. Bugs are probabilistic.
> Good lints don't have just "errors", they report issues
> classified in four or five levels of increasingly probability of
> actual problem being present (naming them something like "Info",
> "Note", "Warning", "Probable Error", and "Error").

If it's not something that _must_ be fixed, the compiler should _not_ complain about it precisely because you should _never_ leave any warnings in committed code. Leaving warnings in committed code (even if invalid) leads to valid warnings being missed and/or ignored, which leads to bugs being uncaught. If a compiler restricts itself to stuff which is _definitively_ wrong, then that isn't a problem. A compiler is _not_ a lint tool and shouldn't be treated as one.

> > But certainly the normal thing to do would be to make -wi the default. It'll never happen, but it would be how most compilers work.
> 
> Thank you Jonathan for the very nice way you kill this idea ;-) I have some faith in future improvements still.

It'll never happen because you'll never convince Walter of it. As Nick points out, it was a miracle to get him to add -wi in the first place. Feel free to try, but I'd be _very_ surprised if you managed it.

- Jonathan M Davis

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.406.1336442026.24740.digitalmars-d@puremagic.com...
>
> And -w is _completely_ unique AFAIK.

No, -w is literally the same as "Treat warnings as errors", which many compilers have (esp. C/C++). DMD is just unique in *calling* it "Warnings" instead of "Treat warnings as errors".


> That said, I increasingly agree with Walter's philosophy that something
> should
> either be an error or not and that warnings are flawed by nature.

I always felt (and still do) that that's an overly puritanical view of reality. In an ideal world, yes, there should be no need for warnings and everything is either right or wrong. Problem is, reality sucks, and there are times when it's impratical or unrealistic to cram a bit of grey into that binary "right-or-wrong" mold. Hence, warnings.


> So, nothing
> which is a warning is really any different from an error except for the
> fact
> that it may be reasonable to leave it alone temporarily while editing or
> debugging code.

I consider that a very strong argument *in favor* of warnings having real value.

Of course, this isn't to say that there aren't any warnings we should change into errors. Mandatory flow-control at the end of a "case:" block is a prime example, IMHO.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.407.1336445190.24740.digitalmars-d@puremagic.com...
> On Tuesday, May 08, 2012 04:21:06 bearophile wrote:
>> Jonathan M Davis:
>> > A good programmer will never leave _any_ warnings in committed code.
>>
>> Sometimes warnings are wrong, the compiler is not perfect.
>> If the compiler is certain there is a mistake in the code, then
>> generating an error is better. Bugs are probabilistic.
>> Good lints don't have just "errors", they report issues
>> classified in four or five levels of increasingly probability of
>> actual problem being present (naming them something like "Info",
>> "Note", "Warning", "Probable Error", and "Error").
>
> If it's not something that _must_ be fixed, the compiler should _not_
> complain
> about it precisely because you should _never_ leave any warnings in
> committed
> code. Leaving warnings in committed code (even if invalid) leads to valid
> warnings being missed and/or ignored, which leads to bugs being uncaught.
> If a
> compiler restricts itself to stuff which is _definitively_ wrong, then
> that
> isn't a problem. A compiler is _not_ a lint tool and shouldn't be treated
> as
> one.
>

A compiler isn't a profilier, documentation generator or unittesting tool either, but a big part of D's philosophy is that there *is* real value in having such things in the compiler anyway. The more significant warnings should normally be on (ie, stuff that's ok while debuggng, but shouldn't be checked in), but lint-style pedantic analysis likely *shouldn't* be enabled on every build anyway, so the "stuff getting ignored" argument doesn't really apply.

And as I said some time ago, if you still *really* want a line tool to be separate from the compiler for whatever "purity" or ideological reason, that'd be easy enough to do:

$cat dlint
#!/bin/bash
dmd -lint "$*"
#or
dmd -pedantic-warnings "$*"