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
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
May 07 2012
next sibling parent =?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
 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
May 07 2012
prev sibling next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
--0015175cf89efceaa304bf7abb0a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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. --0015175cf89efceaa304bf7abb0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p><br> On May 7, 2012 7:33 PM, &quot;Alex R=C3=B8nne Petersen&quot; &lt;<a href=3D= "mailto:xtzgzorex gmail.com">xtzgzorex gmail.com</a>&gt; wrote:<br> &gt;=C2=A0 (I mean, we&#39;re D, not C; we don&#39;t have over 9000 warning= variants).<br> &gt;<br> &gt; -- <br> &gt; - Alex</p> <p>Yet.<br> </p> --0015175cf89efceaa304bf7abb0a--
May 07 2012
prev sibling next 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
 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!)
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
 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
May 07 2012
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 next sibling parent "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
prev sibling next sibling 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 "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 #!/bin/bash dmd -lint "$*" #or dmd -pedantic-warnings "$*"
May 07 2012
prev sibling next sibling 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 #!/bin/bash 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
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 next 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
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