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


<snip>

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

Stewart.
Apr 21 2012
next sibling parent reply "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.  "


 <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
Apr 21 2012
parent reply "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
parent reply "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
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.


<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.
Apr 25 2012
parent reply 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
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
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 reply 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
parent reply 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
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 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 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 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


<snip>

cast(void) r.front;

Stewart.
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 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
 }()));
 }


<snip>

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)

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
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 parent reply "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
parent reply "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
next sibling 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 "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
prev sibling next sibling parent reply 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
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
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 parent reply 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
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 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 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!



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.


than the lack of one in C/C++. But D already has a solution and does not Java 


- Jonathan M Davis
Apr 21 2012