GCC 4.6

[bearophile]

Walter:

> You quoted a claim saying it was also an optimization.

If GCC devs say so, then I presume they are right. But the main purpose of a warning is to warn the programmer, in this case to avoid some bugs.


> As I said, these kinds of error messages are very annoying when developing code, 
> for example, when enabling and disabling various sections.

Warnings have a cost. Sometimes they are locally wrong, becoming noise, so in some situations people want to disable specific warnings locally (GCC 4.6 has added ways to do this).

In some situations I agree that an error is better than a warning message, indeed D has turned some C warnings into errors. There are even two D warnings that I want to become errors:
http://d.puremagic.com/issues/show_bug.cgi?id=3836
http://d.puremagic.com/issues/show_bug.cgi?id=4216

Elsewhere you have explained that different compilers have different warnings, this combined with the choice of many programmers to see warnings as errors produces incompatible programs, it means that changing the compiler becomes almost like changing language (a possible solution I see to this problem is to standardize most warnings in a language. So most warnings are shared between compilers of the same language).

Regarding what you say here, I agree that when you develop a part of code you want a little more local freedom. Because you often have some scaffolding code, variables, etc, that you use to build the main code. This means that in code that's work in progress you sometimes have duplicated variables, redundancies, and several other things that are probably seen as problems by a more strict compiler.

On the other hand, the amount of code you work in a moment is not large, so the amount of warnings your program generates is not large (assuming most other part of the code don't generate warnings or have silenced warnings), so I think such limited amount of warnings is going to be acceptable. Maybe there is a way to disable the warnings in just the parts of the program you are working now. But warnings sometimes are useful, so they may catch bugs you are adding in the new code you are adding/changing now.

The most part of a largish program is not under change in any moment (even if many people are working on a program at the same time). And experience has shown me that unused variables in cold code (code you are not modifying right now) are sometimes associated with bugs or other troubles (this was also the main point of that paper by Yichen Xie). And removing them helps make the code shorter, more tidy. It's worse than leaving useless phrases in a text.


> I get told I'm wrong on just about everything I do.

In D language/compiler I have found many good decisions, most of them are good, that's why I am here :-) But there are things I don't agree with, and I try to explain why.


Like that section 3 page 2 "Redundant assignments" on the Yichen Xie paper. In my code and code written by other people I have seen many times little errors like this, or several similar variations of it:

class Foo {
  int x, y, z;
  Foo(int x_, int y_, int z_) {
    x = x_;
    y = y;
    z = z_;
  }
...
}


If the lint is able to spot redundant assignments, it shows a warning. A compiler may even turn redundant assignments into errors. D turns unassigned pure expressions into errors:

void main() {
    int x = 10;
    int y = 20;
    x + y;
}

test.d(4): Error: + has no effect in expression (x + y)


But currently this gives no errors, despite it's the same situation, so I'd like an error here too (this enhancement request is in Bugzilla already):

pure int add(int a, int b) { return a + b; }
void main() {
    int x = 10;
    int y = 20;
    add(x, y);
}


In the paper by Yichen Xie you see many other interesting cases, that come from real world code, it's quite interesting stuff.

Bye,
bearophile