On Monday 18 October 2010 04:39:00 bearophile wrote: > Jonathan M Davis: > > The problem is that there are a lot of things that you can warn about > > which aren't necessarily a problem, and it can be really annoying to > > have to fix a bunch of useless warnings. If it really matters, then it > > should be an error. And if it doesn't really matter, then do we need to > > warn about? > > This is a quite manichaean view of the programming world, but life isn't > like that, it comes in shades of grey. I suggest you to read the book > "Fuzzy Thinking: The New Science of Fuzzy Logic" by Bart Kosko, to help > your mind grow up a bit. > > And sometimes even when the situation is clear for a human, a less smart > compiler may be unsure, so it has to give a probability weighting of the > situation. Some lint tools literally partition their messages in classes > based on their truth probability. > > And then, keep in mind I was not talking about warnings in this post, but > more about compiler tips. A performance tip, even when it's 100% certain, > is not something you must listen to. It may be useful if you are > performance-tuning a function, otherwise you may ignore it. This is why I > have said they are a third kind of compiler message. > > > I'm not entirely against warnings, but I do think that there are a lot of > > things that keep getting proposed as warnings (particularly by > > Bearophile) which are far more likely to be annoying to fix non-problems > > than to actually be a problem and that such warnings would be far better > > suited to a lint-like tool than the compiler. > > There are two things to say about lint tools: > - They are really really useful if you write C code. And I think they may > be useful for D code too. - Lot of people aren't using them. I know older > programmers that didn't even know what a lint is. In my opinion one way to > avoid this is to put some lint-capabilities inside the compiler. > > Putting a whole lint inside the compiler is probably not a good idea, > because they a good lint is complex. So I think it's a good thing to put > some simple lint functionality inside the dmd compiler. In Bugzilla I have > added some enhancement requests about this, that have received many > comments from people. > > Bye, > bearophile
I, for one, want the compiler to tell you about things that are either absolutely guaranteed to be a problem or things which are _highly_ likely to be a problem. Anything less that doesn't belong in the compiler IMHO. If it's in the compiler, then it's going to be bugging me every time that I compile. If it's in a separate tool (or in a totally separate mode used by the compiler which isn't normal compilation), then I can use it when I want to be more thorough, but I do _not_ want to have the compiler throwing warnings at me left and right for things that _might_ be a problem. I much prefer it will the compiler restricts itself to things that are guaranteed to be problems (and perhaps some things that are _almost_ guaranteed). A lot of the kinds of warnings (or tips) that you like to suggest are exactly the kind of things that I don't think that compiler should be complaining about. Obviously, you don't agree, but that's how I see things. - Jonathan M Davis
