View mode: basic / threaded / horizontal-split · Log in · Help
April 25, 2012
Re: Docs: Section on local variables
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
Re: Docs: Section on local variables
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
Re: Docs: Section on local variables
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
Re: Docs: Section on local variables
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
Re: Docs: Section on local variables
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
Re: Docs: Section on local variables
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
Re: Docs: Section on local variables
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
Re: Docs: Section on local variables
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
Re: Docs: Section on local variables
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
Re: Docs: Section on local variables
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.
1 2 3 4
Top | Discussion index | About this forum | D home