Can I remove this section from the D docs, in functions? :

"
Local Variables
It is an error to use a local variable without first assigning it a
value. The implementation may not always be able to detect these
cases. Other language compilers sometimes issue a warning for this,
but since it is always a bug, it should be an error.

It is an error to declare a local variable that is never referred to.
Dead variables, like anachronistic dead code, are just a source of
confusion for maintenance programmers.
"

I don't think this will ever be implemented, or that it should be for that matter.

On 20/04/2012 01:53, Andrej Mitrovic wrote:
> Can I remove this section from the D docs, in functions? :
>
> "
> Local Variables
> It is an error to use a local variable without first assigning it a
> value. The implementation may not always be able to detect these
> cases. Other language compilers sometimes issue a warning for this,
> but since it is always a bug, it should be an error.

This does seem to be a total contradiction of the principle that's stated elsewhere in the D spec that variables are always initialised.

> It is an error to declare a local variable that is never referred to.
> Dead variables, like anachronistic dead code, are just a source of
> confusion for maintenance programmers.
> "
<snip>

Why do you want to be able to declare local variables and then never use them?

Stewart.

On Sat, Apr 21, 2012 at 01:03:13PM +0100, Stewart Gordon wrote:
> On 20/04/2012 01:53, Andrej Mitrovic wrote:
[...]
> >It is an error to declare a local variable that is never referred to. Dead variables, like anachronistic dead code, are just a source of confusion for maintenance programmers.  "
> <snip>
> 
> Why do you want to be able to declare local variables and then never use them?
[...]

It happens a lot when you're debugging code (temporarily comment out some stuff for testing purposes). It would be a major pain if every single time you need to temporarily suppress a section of code, you also have to hunt down every last stray variable that's now no longer referenced in the function and comment them out as well. And then do the reverse after you're done testing whatever it is you're trying to debug.

(Yes, yes, I know variables are supposed to be declared right before they're used, not at the top of the function... but sometimes things move apart after enough code iterations.)


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond

On 4/21/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> It would be a major pain if every
> single time you need to temporarily suppress a section of code, you also
> have to hunt down every last stray variable that's now no longer
> referenced in the function and comment them out as well.

Next thing you know the compiler will start warning me when I indent my code with uneven number of spaces!

H. S. Teoh:

>> Why do you want to be able to declare local variables and then never use them?
> [...]
>
> It happens a lot when you're debugging code (temporarily comment out
> some stuff for testing purposes). It would be a major pain if every
> single time you need to temporarily suppress a section of code, you also
> have to hunt down every last stray variable that's now no longer
> referenced in the function and comment them out as well. And then do the
> reverse after you're done testing whatever it is you're trying to debug.

How do Go programmers cope with this (I think in Go unused variables are errors)?

So are you saying that in 'finished' code (when you aren't working on it) you don't want unused variables? So do you prefer just an unused variable warning that comes out only when you use "-wi/-w"? A problem I've seen in D.learn is that lot of people here doesn't seem to use -wi/-w. Or maybe, on the contrary, this unused variable error should be suppressed only if the D code is compiled with "-debug"?


> (Yes, yes, I know variables are supposed to be declared right before
> they're used, not at the top of the function... but sometimes things
> move apart after enough code iterations.)

Then adding some pressure to remind to keep such distance short may be a good thing :-)


And beside unused variables, there is also this:
http://d.puremagic.com/issues/show_bug.cgi?id=4694

Bye,
bearophile

On Sat, Apr 21, 2012 at 06:42:06PM +0200, bearophile wrote:
> H. S. Teoh:
> 
> >>Why do you want to be able to declare local variables and then never use them?
> >[...]
> >
> >It happens a lot when you're debugging code (temporarily comment out some stuff for testing purposes). It would be a major pain if every single time you need to temporarily suppress a section of code, you also have to hunt down every last stray variable that's now no longer referenced in the function and comment them out as well. And then do the reverse after you're done testing whatever it is you're trying to debug.
[...]
> So are you saying that in 'finished' code (when you aren't working on it) you don't want unused variables?

In finished code, it's obviously a bad thing to have unused variables (unless the compiler optimizes them away, but that's not happening 'cos it depends on flow analysis, which would have let us spit out warnings about it in the first place.)


> So do you prefer just an unused variable warning that comes out only when you use "-wi/-w"? A problem I've seen in D.learn is that lot of people here doesn't seem to use -wi/-w. Or maybe, on the contrary, this unused variable error should be suppressed only if the D code is compiled with "-debug"?

I don't know if conflating unused variable warnings with -debug is a good thing. Just like the conflation of -release with the opposite of -debug or -unittest.


> >(Yes, yes, I know variables are supposed to be declared right before they're used, not at the top of the function... but sometimes things move apart after enough code iterations.)
> 
> Then adding some pressure to remind to keep such distance short may be a good thing :-)

This is not always possible. Sometimes you *need* to declare a variable outside a loop, which is only used much deeper inside the loop, because it needs to persist across iterations. Moving it close to where it's used breaks its semantics.


> And beside unused variables, there is also this: http://d.puremagic.com/issues/show_bug.cgi?id=4694
[...]

In my mind, that's a more general issue that includes detecting unused variables as a special case. Both depend on flow analysis, which apparently Walter is not fond of (I can't tell why). Both are nice to have, but I don't know if it will happen.


T

-- 
Without outlines, life would be pointless.

On Sat, Apr 21, 2012 at 06:26:52PM +0200, Andrej Mitrovic wrote:
> On 4/21/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> > It would be a major pain if every single time you need to temporarily suppress a section of code, you also have to hunt down every last stray variable that's now no longer referenced in the function and comment them out as well.
> 
> Next thing you know the compiler will start warning me when I indent my code with uneven number of spaces!

And dlang.org gets mysteriously renamed to python4.org ...

:-P


T

-- 
Programming is not just an act of telling a computer what to do: it is also an act of telling other programmers what you wished the computer to do. Both are important, and the latter deserves care. -- Andrew Morton

On Saturday, April 21, 2012 18:26:52 Andrej Mitrovic wrote:
> On 4/21/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> > It would be a major pain if every
> > single time you need to temporarily suppress a section of code, you also
> > have to hunt down every last stray variable that's now no longer
> > referenced in the function and comment them out as well.
> 
> Next thing you know the compiler will start warning me when I indent my code with uneven number of spaces!

It's not quite as bad as all that. It works reasonably well in Java and C# and for the most part isn't a big deal, but for D, init already solves the larger problem of variables with garbage values, and adding forced initializations on top of that definitely isn't worth it - especially when it requires flow control and can give false positives at times.

I don't think that there's much question that Java and C#'s solution is better than the lack of one in C/C++. But D already has a solution and does not Java and C#'s on top of it.

- Jonathan M Davis

On 21/04/2012 19:24, H. S. Teoh wrote:
<snip>
> In finished code, it's obviously a bad thing to have unused variables
> (unless the compiler optimizes them away,

Whether the compiler optimises it away or not, an unused variable is a code smell. Complaining about unused variables serves as a warning to the programmer that there's probably a bug in the program.  Even if it's left over from debugging, it looks silly, and might lead other people reading the code to believe something's wrong.

> but that's not happening 'cos
> it depends on flow analysis, which would have let us spit out warnings
> about it in the first place.)

How does seeing that there are no references to a variable anywhere in its scope depend on flow analysis?

>> So do you prefer just an unused variable warning that comes out only
>> when you use "-wi/-w"? A problem I've seen in D.learn is that lot of
>> people here doesn't seem to use -wi/-w.

So you think compiler warnings should be compulsory - with perhaps a CLO just to control whether they cause the compilation to fail?

>> Or maybe, on the contrary,
>> this unused variable error should be suppressed only if the D code is
>> compiled with "-debug"?
>
> I don't know if conflating unused variable warnings with -debug is a
> good thing. Just like the conflation of -release with the opposite of
> -debug or -unittest.
<snip>

I don't really like this idea either.  The point of -debug is to add code to the program for debugging.  You might need to switch this debugging code on/off independently of whether you have unused variables.

Two possibilities I can see:
- Keep the statement in the spec, and fix DMD to implement it properly.  Maybe add a CLO to suppress errors such as this one that are only there to catch bugs.
- Remove the statement from the spec, and implement a warning in DMD.

Stewart.

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.