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 would end up being a PITA with false errors, and I felt that C# demonstrates 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 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.

 didn't need to be, and perhaps even *shouldn't* be, perfect. He felt that
 would end up being a PITA with false errors, and I felt that C#
 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 "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.

Wow, as much as I like it, that's very non-D-like. C# has it which I always 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
prev sibling next sibling parent "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
 would end up being a PITA with false errors, and I felt that C# 
 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
prev sibling next 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 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 "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
prev sibling next sibling parent "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
prev sibling 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 next 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 "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