April 25, 2012
On Wed, 25 Apr 2012 13:30:09 +0200, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> On 21/04/2012 17:26, Andrej Mitrovic wrote:
> <snip>
>> Next thing you know the compiler will start warning me when I indent
>> my code with uneven number of spaces!
>
> Or more usefully, warn if you have a mishmash of tab and space indentation.
>
> How do indent-sensitive languages (Haskell, Python, whatever else) deal with mixed tab/space indentation, for that matter?
>
> Stewart.

They give you horrible, difficult to find bugs :)
April 25, 2012
On 4/25/12, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> Even if it's left over from debugging, it
> looks silly, and
> might lead other people reading the code to believe something's wrong.

There's about a million ways to make code unreadable, and nobody writes pitch-perfect code that has absolutely no leftover code or comments.

And what if you're refactoring and you do multiple builds every couple of seconds? You add a variable, remove it, etc etc. Enabling this warning will just make for a noisy compiler. Keeping variables clean is the responsibility of the programmer and not the compiler.

If it doesn't affect the semantics of code the compiler should shut up. Please don't turn the compiler into a reincarnation of Clippy.
April 25, 2012
On 25/04/2012 17:10, Andrej Mitrovic wrote:
> On 4/25/12, Stewart Gordon<smjg_1998@yahoo.com>  wrote:
>> Even if it's left over from debugging, it
>> looks silly, and
>> might lead other people reading the code to believe something's wrong.
>
> There's about a million ways to make code unreadable, and nobody
> writes pitch-perfect code that has absolutely no leftover code or
> comments.

Exactly.  But good-quality compilers help programmers in that direction in various ways.

> And what if you're refactoring and you do multiple builds every couple
> of seconds? You add a variable, remove it, etc etc. Enabling this
> warning will just make for a noisy compiler.

But if the spec stays the same, the compiler needs to generate an _error_ for it in order to conform.  If this statement is removed from the spec, then it will be a matter of adding a warning.  But this is part of why warnings are optional in DMD.  By enabling warnings in the compiler in the first place, the programmer is asking to be informed of things like this.

> Keeping variables clean
> is the responsibility of the programmer and not the compiler.
>
> If it doesn't affect the semantics of code the compiler should shut
> up. Please don't turn the compiler into a reincarnation of Clippy.

So you think that

import std.stdio;
void main() {
    int a, b;
    a + b;
    return;
    writefln("Hello, world!");
}

should generate no errors or warnings whatsoever?

Stewart.
April 25, 2012
On Wednesday, April 25, 2012 20:10:18 Stewart Gordon wrote:
> On 25/04/2012 17:10, Andrej Mitrovic wrote:
> > On 4/25/12, Stewart Gordon<smjg_1998@yahoo.com> wrote:
> >> Even if it's left over from debugging, it
> >> looks silly, and
> >> might lead other people reading the code to believe something's wrong.
> > 
> > There's about a million ways to make code unreadable, and nobody writes pitch-perfect code that has absolutely no leftover code or comments.
> 
> Exactly. But good-quality compilers help programmers in that direction in various ways.
> > And what if you're refactoring and you do multiple builds every couple of seconds? You add a variable, remove it, etc etc. Enabling this warning will just make for a noisy compiler.
> 
> But if the spec stays the same, the compiler needs to generate an _error_ for it in order to conform. If this statement is removed from the spec, then it will be a matter of adding a warning. But this is part of why warnings are optional in DMD. By enabling warnings in the compiler in the first place, the programmer is asking to be informed of things like this.
> 
> > Keeping variables clean
> > is the responsibility of the programmer and not the compiler.
> > 
> > If it doesn't affect the semantics of code the compiler should shut up. Please don't turn the compiler into a reincarnation of Clippy.
> 
> So you think that
> 
> import std.stdio;
> void main() {
> int a, b;
> a + b;
> return;
> writefln("Hello, world!");
> }
> 
> should generate no errors or warnings whatsoever?

The only part of that that I'd want to give an error is what currently gives an error - the line with a + b due to the fact that it has no effect. There's no reason for such a line to exist even while debugging. But having the compiler complain about unused variables and/or unreachable code gets to be _really_ annoying when editing code - especially when adding and removing stuff during debugging.

Unfortunately, the writefln line _does_ result in an error for unreachable code when compiled with -w, but at least it's not an error normally. Still, I'd prefer if it weren't even a warning - especially since increasingly I agree with Walter's take on warnings (that they shouldn't exist at all - something is an error or it isn't; none of this halfway stuff). Warnings are problematic in that a good programmer will _never_ leave them in their code and yet so many programmers do. So, they become useless noise. The _only_ advantage to them is that they can be used for stupid stuff like unreachable code, allowing you to leave warnings while editing code but remove them when your done. I don't really even like that though, truth be told.

- Jonathan M Davis
April 25, 2012
On 4/25/12, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> So you think that
>
> import std.stdio;
> void main() {
>      int a, b;
>      a + b;
>      return;
>      writefln("Hello, world!");
> }
>
> should generate no errors or warnings whatsoever?

I'm really only talking about:
void a() {
int x;
}

And of course:
void a() {
bool state;
...
if (state) { }
}

I'd like the warnings to be individually selectable, just like in GCC.

Btw, here's a trick question, should the compiler warn about this case?

void main() {
    new Foo();  // or even Foo foo = new Foo;
}

:p
April 25, 2012
On 4/25/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> I'm really only talking about

Although I'm not a fan of warnings for unused variables, I would be a fan of this: http://d.puremagic.com/issues/show_bug.cgi?id=3507

But again, other people might not like that. But if it was an option..
April 25, 2012
On Wed, Apr 25, 2012 at 04:03:04PM -0400, Jonathan M Davis wrote: [...]
> increasingly I agree with Walter's take on warnings (that they shouldn't exist at all - something is an error or it isn't; none of this halfway stuff). Warnings are problematic in that a good programmer will _never_ leave them in their code and yet so many programmers do. So, they become useless noise. The _only_ advantage to them is that they can be used for stupid stuff like unreachable code, allowing you to leave warnings while editing code but remove them when your done. I don't really even like that though, truth be told.
[...]

The other advantage is that they let you identify code written by incompetent programmers.


T

-- 
"No, John.  I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev
April 25, 2012
On Wednesday, April 25, 2012 22:12:02 Andrej Mitrovic wrote:
> I'd like the warnings to be individually selectable, just like in GCC.

Having sets of warnings that you can explicitly enable makes a lot of sense, because it enables the programmer to have the compiler warn about stuff that they care about, whereas if it's something that everyone is going to consider a problem, then why isn't it an error? However, Walter doesn't like having a lot of compiler flags, and warnings pretty much only exist at all because people begged him for them. So, I don't see dmd ever having a bunch of warning flags as much as it might be desirable.

- Jonathan M Davis
April 25, 2012
On 25/04/2012 21:12, Andrej Mitrovic wrote:
<snip>
> I'm really only talking about:
> void a() {
> int x;
> }

What is the distinction you're making exactly?

> And of course:
> void a() {
> bool state;
> ...
> if (state) { }
> }

You mean an empty if body should trigger something?  Or shouldn't?

OK, so I can see a similarity in that it's likely to occur when disabling portions of code for debugging purposes.  Not just debugging the program in which it is present, but also creating testcases for compiler/library bug reports.

> I'd like the warnings to be individually selectable, just like in GCC.
>
> Btw, here's a trick question, should the compiler warn about this case?
>
> void main() {
>      new Foo();  // or even Foo foo = new Foo;
> }

An interesting one.  Sometimes a constructor may hook the object up to something.  I've probably done this myself on a number of occasions.  Though I can't think of examples OTTOMH.  But an example in C++ comes from my last job.  The application framework developed in-house includes a class template used to trigger events on construction and destruction.  To use it, one would just construct an object of that type.  In many cases, it would just be a declaration of a variable of that type (since C++ classes are value types) - the variable will never be used again, but the object's construction triggers stuff.

Stewart.
April 25, 2012
On 4/25/12, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> What is the distinction you're making exactly?
> You mean an empty if body should trigger something?  Or shouldn't?

I'm saying those are exactly the cases presented in the docs and I don't want them to warn by default but have a setting. I mean, the first case (warn on unused variables), I just might get used to. But warning on reading before writing is an extreme change from current behavior imho.

> Sometimes a constructor may hook the object up to something.

Yup. E.g.:

class Foo
{
    static Foo[] objects;
    this()
    {
        objects ~= this;
    }
}

IIRC I've seen this used in Harmonia and maybe in some places on some github project (I think it was actually the D forum software). The compiler might not even know what the ctor does if all it has is the .di file of the module where the class is defined.