www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - -wi on default?

reply "bearophile" <bearophileHUGS lycos.com> writes:
They are discussing about having -Wall on default in GCC 4.8:

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


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
May 07 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
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


 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
May 07 2012
next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
On May 7, 2012 7:33 PM, "Alex R=C3=B8nne Petersen" <xtzgzorex gmail.com> wr=
ote:

  (I mean, we're D, not C; we don't have over 9000 warning variants).

 --
 - Alex


Yet.
May 07 2012
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
May 07 2012
prev sibling next sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"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


 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!)
May 07 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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

 
 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
May 07 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
May 07 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
May 07 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"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

dmd -lint "$*"
#or
dmd -pedantic-warnings "$*"
May 07 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, May 07, 2012 23:56:40 Nick Sabalausky wrote:

 "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

 dmd -lint "$*"
 #or
 dmd -pedantic-warnings "$*"


I think that it makes sense to have flags for enabling certain types of 
warnings. The programmer can then choose to enable warnings for the things 
that that they want to warn about (be it on all builds or just on a build 
which is intended to check for the type of stuff that lint checks for). What I 
do _not_ want to see is for such warnings to be part of -wi or -w.

I'm _very_ much against having normal warnings which are things which don't 
definitively need to be fixed, because otherwise you get into the situation 
where people ignore them, and the quality of the software suffers, because you 
get a ton of warnings that don't get fixed, some of which _need_ to get fixed 
and others which just hide those warnings by helping to make the number of 
warnings too many to examine. Optional flags for additional warnings don't 
introduce quite the same problem (though obviously if you always insist on 
them for your builds, you risk the same problems as if they were part of -wi).

However, as I understand it, Walter is against having a bunch of different
flags 
for enabling or disabling different warnings, so it's unlikely that we're going 
to get that with dmd, regardless of whether it would be an improvement or not.

- Jonathan M Davis
May 07 2012
next sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.408.1336451614.24740.digitalmars-d puremagic.com...

 I think that it makes sense to have flags for enabling certain types of
 warnings. The programmer can then choose to enable warnings for the things
 that that they want to warn about (be it on all builds or just on a build
 which is intended to check for the type of stuff that lint checks for). 
 What I
 do _not_ want to see is for such warnings to be part of -wi or -w.

 I'm _very_ much against having normal warnings which are things which 
 don't
 definitively need to be fixed, because otherwise you get into the 
 situation
 where people ignore them, and the quality of the software suffers, because 
 you
 get a ton of warnings that don't get fixed, some of which _need_ to get 
 fixed
 and others which just hide those warnings by helping to make the number of
 warnings too many to examine. Optional flags for additional warnings don't
 introduce quite the same problem (though obviously if you always insist on
 them for your builds, you risk the same problems as if they were part 
 of -wi).

 However, as I understand it, Walter is against having a bunch of different 
 flags
 for enabling or disabling different warnings, so it's unlikely that we're 
 going
 to get that with dmd, regardless of whether it would be an improvement or 
 not.


Ok, yea, I completely agree on all counts.
May 07 2012
prev sibling parent "Pierre LeMoine" <yarr.luben+dlang gmail.com> writes:
On Tuesday, 8 May 2012 at 04:32:14 UTC, Jonathan M Davis wrote:

 ...
 I'm _very_ much against having normal warnings which are things 
 which don't
 definitively need to be fixed, because otherwise you get into 
 the situation
 where people ignore them, and the quality of the software 
 suffers, because you
 get a ton of warnings that don't get fixed, some of which 
 _need_ to get fixed
 and others which just hide those warnings by helping to make 
 the number of
 warnings too many to examine. Optional flags for additional 
 warnings don't
 introduce quite the same problem (though obviously if you 
 always insist on
 them for your builds, you risk the same problems as if they 
 were part of -wi).
 ...


If that's a problem, then why not add a parameter which says how 
many warnings to tolerate before treating them (all the errors up 
to this point) as an error, and make the default value for this 
parameter relatively strict? I'm sure i've seen this 
functionality in other compilers/tools.

/Pierre
May 08 2012
prev sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"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.
May 07 2012
prev sibling parent "Pierre LeMoine" <yarr.luben+dlang gmail.com> writes:
On Monday, 7 May 2012 at 23:25:56 UTC, bearophile wrote:

 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)?


It sounds like a good idea to me, I'm all for it. The more 
warnings i get, the less probable i am to make wierd, subtle 
errors that are hard to track down.
May 08 2012