www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Docs: Section on local variables

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Apr 19 2012
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
 "

Why do you want to be able to declare local variables and then never use them? Stewart.
Apr 21 2012
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.

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.
Apr 25 2012
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Apr 25 2012
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Apr 25 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/25/2012 06:10 PM, 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. 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.

+1. Another thing: It might not be unused in every static code path. Even more important: template isInputRange(R) { enum bool isInputRange = is(typeof( { R r; // can define a range object if (r.empty) {} // can test for empty r.popFront(); // can invoke popFront() auto h = r.front; // can declare an unused variable }())); } Having these kinds of errors in the compiler would be a major PITA that butchers the language without any benefit for correct code. This should not be the responsibility of the compiler. It is not a good match for D.
Apr 26 2012
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 26/04/2012 08:26, Timon Gehr wrote:
<snip>
 Another thing: It might not be unused in every static code path.

One way to deal with this would be to do the checking before conditional compilation. That said, I've a feeling that mixin expansion might get in the way of this.
 Even more important:

 template isInputRange(R)
 {
 enum bool isInputRange = is(typeof(
 {
 R r; // can define a range object
 if (r.empty) {} // can test for empty
 r.popFront(); // can invoke popFront()
 auto h = r.front; // can declare an unused variable

cast(void) r.front; Stewart.
Apr 26 2012
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 26/04/2012 08:26, Timon Gehr wrote:
<snip>
 template isInputRange(R)
 {
 enum bool isInputRange = is(typeof(
 {
 R r; // can define a range object
 if (r.empty) {} // can test for empty
 r.popFront(); // can invoke popFront()
 auto h = r.front; // can declare an unused variable
 }()));
 }

This is indeed a blocker for fixing it to work according to the current spec. I've just filed http://d.puremagic.com/issues/show_bug.cgi?id=7989 to address it. Stewart.
Apr 26 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 26/04/2012 15:05, Stewart Gordon wrote:
<snip>
 http://d.puremagic.com/issues/show_bug.cgi?id=7989

From JMD: "The fact that isInputRange and isForwardRange rely on declaring variables which aren't used being legal. It would be really annoying for unused local variables to be illegal when dealing with template constraint stuff like isInputRange and isForwardRange. Code would have to be needlessly contorted to deal with that fact, and you wouldn't ever get a good error about why the result of the template was false, because it would be part of a template constraint. IHMO, the very issue that this bug report brings up highlights a good reason why unused local variables should continue to be ignored by the compiler." (on 3960) "I think that issue# 7989 is a great argument for why there shouldn't be any warnings or errors for unused variables. Such would needlessly make writing template constraints harder." Since this is relevant to both issues, I'll continue the discussion here. I can begin to see why it makes errors for unused variables a bad idea. But why no warnings? Obviously the user wouldn't like to see warnings thrown at them when they try using templates with such constraints. But: - The average programmer is, the vast majority of the time, not writing template constraints, but trying to write bug-free application code. - A quality compiler would swallow warnings generated by the content of IsExpressions, just as it already swallows errors generated by them - the only difference being that warnings don't cause the IsExpression to return false. Stewart.
Apr 26 2012
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 26/04/2012 22:52, bearophile wrote:
<snip>
 For uncommon situations like isInputRange a specific annotation
 solves the problem cleanly.

As does the compiler swallowing warnings in the content of an IsExpression as I already suggested. <snip>
 How many C/C++ programmers do you know that use lints?  I think not
 enough.  The Microsoft C++ compiler and Clang are adding more and
 more compile-time tests, replacing lints, this a trend D designers
 can't ignore.  So saying "leave it to lints" it's almost like
 saying "ignore the problem".

I agree. http://dlang.org/overview.html under "Who D is for": "Programmers who routinely use lint or similar code analysis tools to eliminate bugs before the code is even compiled." My impression from this has been that D aims to eliminate (or at least minimise) the need to use lint-type tools, by making the code smells lint is made to catch illegal code and therefore caught by the compiler. Stewart.
Apr 26 2012
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Apr 25 2012
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 25/04/2012 12:30, Stewart Gordon 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?

Just found out http://urchin.earth.li/~ian/style/haskell.html http://www.secnetix.de/olli/Python/block_indentation.hawk that both Haskell and Python uses a tab size of 8 characters. Personally, I think they should error if the meaning of a section of code depends on the tab size. OTOH, YAML avoids the issue in the strictest way possible: forbidding tab characters. I wonder if there are other languages that require you to indent with tabs. But one possible design for languages like these is to allow indentation to be either entirely spaces or entirely tabs, but not a mixture. This would also be a good way for linters for a variety of languages to behave. Another way would be to allow tabs, spaces or a mixture, with the only restriction being that a given block must be consistently indented with the same sequence of tabs/spaces. Stewart.
Apr 25 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.  "

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
Apr 21 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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!
Apr 21 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Apr 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Apr 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Apr 21 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Apr 21 2012
prev sibling next sibling parent simendsjo <simendsjo gmail.com> writes:
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 :)
Apr 25 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Apr 25 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Apr 25 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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
Apr 25 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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..
Apr 25 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Apr 25 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Apr 25 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Apr 25 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Stewart Gordon:

 But one possible design for languages like these is to allow 
 indentation to be either entirely spaces or entirely tabs, but 
 not a mixture.  This would also be a good way for linters for a 
 variety of languages to behave.

Among the arguments of the Python2.6 interpreter there is also: -t : issue warnings about inconsistent tab usage (-tt: issue errors) "inconsistent tab usage" means mixing tabs and spaces. Bye, bearophile
Apr 26 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 Andrej Mitrovic:
 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.

+1.

I think currently the D compiler doesn't shut up in some cases. Comparing the unused variable warning with Clippy is not good. Clippy gives suggestions, while here the compiler is giving something more like an error message.
 Another thing: It might not be unused in every static code path.

 Even more important:

 template isInputRange(R)
 {
     enum bool isInputRange = is(typeof(
     {
         R r;              // can define a range object
         if (r.empty) {}   // can test for empty
         r.popFront();     // can invoke popFront()
         auto h = r.front; // can declare an unused variable
     }()));
 }

If the unused variable is a warning, and I use "-wi" that code compiles. The warning for unused variables helps me clean up my C code and has avoided me more than one bug. So I'd like this optional warning in the D front-end. I'd even like a warning for variables assigned and then later never read again. Bye, bearophile
Apr 26 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 26 Apr 2012 14:46:38 -0400, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 I can begin to see why it makes errors for unused variables a bad idea.   
 But why no warnings?  Obviously the user wouldn't like to see warnings  
 thrown at them when they try using templates with such constraints.  But:

 - The average programmer is, the vast majority of the time, not writing  
 template constraints, but trying to write bug-free application code.
 - A quality compiler would swallow warnings generated by the content of  
 IsExpressions, just as it already swallows errors generated by them -  
 the only difference being that warnings don't cause the IsExpression to  
 return false.

I think the mechanism is highly desired, but gets in the way in a select few situations. The best answer IMO is to disable that mechanism when it's not desired. It's then an opt-out mechanism that doesn't require instrumenting most code. Some ideas: pragma(used) int x; used int x; -Steve
Apr 26 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, April 26, 2012 19:46:38 Stewart Gordon wrote:
 I can begin to see why it makes errors for unused variables a bad idea. But
 why no warnings? Obviously the user wouldn't like to see warnings thrown
 at them when they try using templates with such constraints. But:

The existence of -w makes it so that warnings are just as bad as errors for something like this, since it makes warnings errors. The result is that there is a minimal difference between warnings and errors with dmd. And honestly, while I agree that code shouldn't normally have unused variables, I so rarely see code with any that I think that it's a complete non-issue in general. I don't even know the last time that I saw an unused variable left in code (except for on purpose in something like isInputRange). I'd much prefer that warning about that sort of thing be left up to a lint-like tool. - Jonathan M Davis
Apr 26 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 I don't even know the last time that I saw an unused
 variable left in code (except for on purpose in something like 
 isInputRange).

So if the compiler warns you of unused variables, this will not cause your code almost no warnings. No troubles for you. For uncommon situations like isInputRange a specific annotation solves the problem cleanly.
 I'd much prefer that warning about that sort of thing be left 
 up to a lint-like tool.

How many C/C++ programmers do you know that use lints? I think not enough. The Microsoft C++ compiler and Clang are adding more and more compile-time tests, replacing lints, this a trend D designers can't ignore. So saying "leave it to lints" it's almost like saying "ignore the problem". Bye, bearophile
Apr 26 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, April 26, 2012 23:52:48 bearophile wrote:
 Jonathan M Davis:
 I don't even know the last time that I saw an unused
 variable left in code (except for on purpose in something like
 isInputRange).

So if the compiler warns you of unused variables, this will not cause your code almost no warnings. No troubles for you. For uncommon situations like isInputRange a specific annotation solves the problem cleanly.

And I'd argue that we might as well save ourselves the trouble of having to deal with yet _another_ special annotation just so that we can have warnings about something which is generally a non-issue. - Jonathan M Davis
Apr 26 2012