www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Docs: Section on local variables

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Can we remove this section from the D docs, in the functions section? :

"
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. The first paragraph is quite extreme. As for the second
one, think about how often you use temporary variables just to test
something out, you wouldn't want to have a compilation error just
because you've temporarily left an unused variable inside a function.
That's my experience anywho..

I think these features probably belong to some lint-type tool and not
the compiler.
Apr 19 2012
next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 20 April 2012 at 01:22:53 UTC, Andrej Mitrovic wrote:

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

 "
 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. The first paragraph is quite extreme.


Many other languages have this restriction on local variables and
I would love to see DMD do the same kind of analysis. You can't
force programmers to write readable code, but you should at least
discourage it; the current way of default-initializing local
variables and using that as an excuse to not have flow analysis
is extremely weak and just reflects an unwillingness of the DMD
developers to take on this task, affecting the design of the
language.

I have seen this one in the wild before:

for(size_t i; i < arr.length; i++) {
      ...
}

This shouldn't be correct D code, and I think it's one of D's few
weaknesses that it is. Removing this paragraph from the
specification would be designing the language around DMD instead
of the other way around, and I really don't want to see that.


 As for the second one, think about how often you use temporary 
 variables just to test
 something out, you wouldn't want to have a compilation error 
 just
 because you've temporarily left an unused variable inside a 
 function.
 That's my experience anywho..


I think GDC has warnings for this, and I think that's the way to
go. Unused local variables is a plague on readability and we
should strive to eliminate them; but at the same time, a
compilation error for all circumstances may be a little tedious.


 I think these features probably belong to some lint-type tool 
 and not
 the compiler.


If I remember correctly, one of the goals of D according to
Walter is to reduce the need for such external tools.
Apr 20 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Jakob Ovrum" <jakobovrum gmail.com> wrote in message 
news:lehdgtfkqawadxgsgymv forum.dlang.org...

 On Friday, 20 April 2012 at 01:22:53 UTC, Andrej Mitrovic wrote:

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

 "
 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. The first paragraph is quite extreme.


 Many other languages have this restriction on local variables and
 I would love to see DMD do the same kind of analysis. You can't
 force programmers to write readable code, but you should at least
 discourage it; the current way of default-initializing local
 variables and using that as an excuse to not have flow analysis
 is extremely weak and just reflects an unwillingness of the DMD
 developers to take on this task, affecting the design of the
 language.

 I have seen this one in the wild before:

 for(size_t i; i < arr.length; i++) {
      ...
 }

 This shouldn't be correct D code, and I think it's one of D's few
 weaknesses that it is. Removing this paragraph from the
 specification would be designing the language around DMD instead
 of the other way around, and I really don't want to see that.


It's funny, I once argued strongly in favor of this *against* Walter. I lost 
of course ;) IIRC, his argument was that it would require perfect flow 
analysis and that's too difficult and expensive. My argument was that it 
didn't need to be, and perhaps even *shouldn't* be, perfect. He felt that 

it isn't a PITA.  Meh, I don't want to re-debate it though.


 I think these features probably belong to some lint-type tool and not
 the compiler.


 If I remember correctly, one of the goals of D according to
 Walter is to reduce the need for such external tools.


I've argued in the past that warnings *are* a lint tool. The powers that be 
didn't seem to agree though.
Apr 20 2012
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 20 April 2012 at 09:55:04 UTC, Nick Sabalausky wrote:


 It's funny, I once argued strongly in favor of this *against* 
 Walter. I lost
 of course ;) IIRC, his argument was that it would require 
 perfect flow
 analysis and that's too difficult and expensive. My argument 
 was that it
 didn't need to be, and perhaps even *shouldn't* be, perfect. He 
 felt that

 demonstrates
 it isn't a PITA.  Meh, I don't want to re-debate it though.


Yeah, I am aware of Walter's previous statements on this. I think 
it's ridiculous that he wants his language inferior to virtually 
every one of its modern contemporaries in this aspect based on 
implementation issues. I like D's well-defined 
default-initialization and I think it's great for global storage, 
TLS and class/struct fields, but I think local variables require 
a hybrid approach. It doesn't matter if the implementation isn't 
perfect; it's better than the alternative, which is our current 
abysmal situation.
Apr 20 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/20/2012 12:07 PM, Jakob Ovrum wrote:

 On Friday, 20 April 2012 at 09:55:04 UTC, Nick Sabalausky wrote:


 It's funny, I once argued strongly in favor of this *against* Walter.
 I lost
 of course ;) IIRC, his argument was that it would require perfect flow
 analysis and that's too difficult and expensive.


 My argument was that it

 didn't need to be, and perhaps even *shouldn't* be, perfect. He felt that

 demonstrates
 it isn't a PITA. Meh, I don't want to re-debate it though.


 Yeah, I am aware of Walter's previous statements on this. I think it's
 ridiculous that he wants his language inferior to virtually every one of
 its modern contemporaries in this aspect based on implementation issues.


Why do you think it is an implementation issue? D already requires an 
implementation to have flow-analysis.


 I like D's well-defined default-initialization and I think it's great
 for global storage, TLS and class/struct fields, but I think local
 variables require a hybrid approach. It doesn't matter if the
 implementation isn't perfect;


It certainly does. Compiler errors for non-issues hamper productivity 
and are good for nothing.


 it's better than the alternative, which is
 our current abysmal situation.


'abysmal'? Seriously? This could go either way, and personally, I like 
the current way better.

Maybe the implementation could be non-conservative: The warning would 
pop up only if it can be proven by flow-analysis that a local variable 
is accessed without preceding explicit initialisation. Anyway, why would 
this be such a huge deal?
Apr 20 2012
prev sibling next sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.1946.1334885029.4860.digitalmars-d puremagic.com...

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

 "
 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.



liked. But from discussions, Walter seemed very much against it. So I'm very 
surprised that's even there.


 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.
 "


We don't even have a warning for that. (I've asked for one ages ago, but I 
don't think it's gonna happen: 
http://d.puremagic.com/issues/show_bug.cgi?id=2197  - I don't know what the 
hell I was thinking with that over-contrived example though) I wouldn't want 
it to be an error, because like you said, that'd be a PITA for temporary 
code paths, but I always felt it would be helpful as a warning. But, 
uhh...someone...hates warnings though... ;)
Apr 20 2012
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/20/12, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 I don't know what the hell I was thinking with that over-contrived example
though


To be fair, that code is hilarious. All bug reports should have this
sense of humor, imo. :D
Apr 20 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.1973.1334938954.4860.digitalmars-d puremagic.com...

 On 4/20/12, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 I don't know what the hell I was thinking with that over-contrived 
 example though


 To be fair, that code is hilarious. All bug reports should have this
 sense of humor, imo. :D


Heh :)  It's long-winded for what it's trying to say, though. But maybe I'm 
just being overly self-critical.
Apr 20 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Apr 20, 2012 at 06:21:26PM +0200, Andrej Mitrovic wrote:

 On 4/20/12, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 I don't know what the hell I was thinking with that over-contrived example
though


 
 To be fair, that code is hilarious. All bug reports should have this
 sense of humor, imo. :D


Yeah, that deserves a laugh(lang, 7). Or maybe a laugh(lang, 10). But
too much more than that, and it would become laughable. :-P


T

-- 
Век живи - век учись. А дураком помрёшь.
Apr 20 2012
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:


 I think these features probably belong to some lint-type tool 
 and not the compiler.


On the contrary, I hope to see them implemented in the D 
front-end. I've seen again and again that people don't even use 
warnings, so I don't think many of them use lints. This means, 
tests should be built-in and active on default (this means I'd 
like D informational warnings to be active on default, and be 
disabled with a compiler switch!).

Bye,
bearophile
Apr 20 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/20/2012 01:04 PM, bearophile wrote:

 Andrej Mitrovic:


 I think these features probably belong to some lint-type tool and not
 the compiler.


 On the contrary, I hope to see them implemented in the D front-end.
 I've seen again and again that people don't even use warnings, so I don't
 think many of them use lints.
 This means, tests should be built-in and
 active on default (this means I'd like D informational warnings to be
 active on default, and be disabled with a compiler switch!).


I don't usually use warnings because of this issue:
http://d.puremagic.com/issues/show_bug.cgi?id=6552
Apr 20 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:


 I don't usually use warnings because of this issue:
 http://d.puremagic.com/issues/show_bug.cgi?id=6552


Unspecified falltrough is going to become an error, so it's not a 
good example of warning.

And if you are trying to say that warnings are not so good 
because they sometimes warn against something actually correct, 
that's a DMD bug, so again it's not a good example :-)

Regarding the OP topic I have opened:
http://d.puremagic.com/issues/show_bug.cgi?id=3960
http://d.puremagic.com/issues/show_bug.cgi?id=4694

Bye,
bearophile
Apr 20 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/20/2012 03:36 PM, bearophile wrote:

 Timon Gehr:


 I don't usually use warnings because of this issue:
 http://d.puremagic.com/issues/show_bug.cgi?id=6552


 Unspecified falltrough is going to become an error,


Hopefully after the bug is fixed.


 so it's not a good example of warning.


It is a warning now. One example is sufficient.


 And if you are trying to say that warnings are not so good


I am not saying that warnings are not so good. I am saying I don't 
(even) _use_ them currently.


 because they sometimes warn against something actually correct,


I'd claim, most of the time.


 that's a DMD bug,


Not necessarily. Often, warnings have to be conservative. Especially in 
the case discussed in the OP.


 so again it's not a good example :-)


I am not sure what you are trying to say.


 Regarding the OP topic I have opened:
 http://d.puremagic.com/issues/show_bug.cgi?id=3960
 http://d.puremagic.com/issues/show_bug.cgi?id=4694

 Bye,
 bearophile
Apr 20 2012
prev sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Timon Gehr" <timon.gehr gmx.ch> wrote in message 
news:jmrnlo$22p$1 digitalmars.com...

 On 04/20/2012 01:04 PM, bearophile wrote:

 Andrej Mitrovic:


 I think these features probably belong to some lint-type tool and not
 the compiler.


 On the contrary, I hope to see them implemented in the D front-end.
 I've seen again and again that people don't even use warnings, so I don't
 think many of them use lints.
 This means, tests should be built-in and
 active on default (this means I'd like D informational warnings to be
 active on default, and be disabled with a compiler switch!).


 I don't usually use warnings because of this issue:
 http://d.puremagic.com/issues/show_bug.cgi?id=6552


Since implicit fallthrough is going away, that's more a problem with a 
*missing* warning (in the second example) rather than an erroneous warning. 
So not using warnings doesn't solve that, it just makes all the rest of the 
warnings go missing, too.
Apr 20 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Nick Sabalausky:


 Since implicit fallthrough is going away, that's more a problem 
 with a *missing* warning (in the second example) rather than an 
 erroneous warning.


Implicit fallthrough is going away, but Walter has decided to add 
it a special case, when the case is totally empty it's allowed. 
So both programs are correct (I don't love special cases, but 
here I think Walter doesn't want to cause too much D code 
disruption).

Bye,
bearophile
Apr 20 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:monxicizdjzdlakneftc forum.dlang.org...

 Nick Sabalausky:


 Since implicit fallthrough is going away, that's more a problem with a 
 *missing* warning (in the second example) rather than an erroneous 
 warning.


 Implicit fallthrough is going away, but Walter has decided to add it a 
 special case, when the case is totally empty it's allowed. So both 
 programs are correct (I don't love special cases, but here I think Walter 
 doesn't want to cause too much D code disruption).


Oh, that's right, I forgot about that. Nevermind, then.
Apr 20 2012