Tips from the compiler

[Jonathan M Davis]

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