www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is this superfluous?

reply Derek Parnell <derek psych.ward> writes:
I found a mistake in my code today that I was surprised that DMD didn't
mark as an error.

It went something like ...

# void main() 
# {
#    long x,y;    
#    x == y;
#}

In other words, the "x == y;" is a no-operation. I had meant to write "x =
y;" but accidentally added the extra '='.

As DMD is anxious to catch the "if (a = b)" type mistakes, I just assumed
it would mark other potentially silly mistakes too. 

But maybe there is a good reason for it not to ... side-effects maybe?

-- 
Derek
Melbourne, Australia
22/02/2005 11:35:33 AM
Feb 21 2005
next sibling parent reply zwang <nehzgnaw gmail.com> writes:
Derek Parnell wrote:
 I found a mistake in my code today that I was surprised that DMD didn't
 mark as an error.
 
 It went something like ...
 
 # void main() 
 # {
 #    long x,y;    
 #    x == y;
 #}
 
 In other words, the "x == y;" is a no-operation. I had meant to write "x =
 y;" but accidentally added the extra '='.
 
 As DMD is anxious to catch the "if (a = b)" type mistakes, I just assumed
 it would mark other potentially silly mistakes too. 
 
 But maybe there is a good reason for it not to ... side-effects maybe?
 

IMO, no-op checking is the responsibility of a lint program rather than the compiler's. I actually hope DMD could be less fastidious, for example, implicitly converts integer to boolean so that I can write "if (a = b)" statements without being nagged.
Feb 21 2005
parent reply "Craig Black" <cblack ara.com> writes:
"zwang" <nehzgnaw gmail.com> wrote in message 
news:cve3ru$1crf$1 digitaldaemon.com...
 Derek Parnell wrote:
 I found a mistake in my code today that I was surprised that DMD didn't
 mark as an error.

 It went something like ...

 # void main() # {
 #    long x,y;    #    x == y;
 #}

 In other words, the "x == y;" is a no-operation. I had meant to write "x 
 =
 y;" but accidentally added the extra '='.

 As DMD is anxious to catch the "if (a = b)" type mistakes, I just assumed
 it would mark other potentially silly mistakes too. But maybe there is a 
 good reason for it not to ... side-effects maybe?

IMO, no-op checking is the responsibility of a lint program rather than the compiler's. I actually hope DMD could be less fastidious, for example, implicitly converts integer to boolean so that I can write "if (a = b)" statements without being nagged.

That would be nice if you like bugs in your code. And don't tell me you've never done a = b when you meant a == b. Everyone does it! That and leaving out a semicolon once in a while. Yes, compiler warnings can be quite annoying, but they also help uncover a lot of bugs that would otherwise be overlooked. -Craig
Feb 22 2005
parent reply J C Calvarese <jcc7 cox.net> writes:
In article <cvfn4j$i35$1 digitaldaemon.com>, Craig Black says...
"zwang" <nehzgnaw gmail.com> wrote in message 
news:cve3ru$1crf$1 digitaldaemon.com...
 Derek Parnell wrote:
 I found a mistake in my code today that I was surprised that DMD didn't
 mark as an error.

 It went something like ...

 # void main() # {
 #    long x,y;    #    x == y;
 #}

 In other words, the "x == y;" is a no-operation. I had meant to write "x 
 =
 y;" but accidentally added the extra '='.

 As DMD is anxious to catch the "if (a = b)" type mistakes, I just assumed
 it would mark other potentially silly mistakes too. But maybe there is a 
 good reason for it not to ... side-effects maybe?

IMO, no-op checking is the responsibility of a lint program rather than the compiler's. I actually hope DMD could be less fastidious, for example, implicitly converts integer to boolean so that I can write "if (a = b)" statements without being nagged.

That would be nice if you like bugs in your code. And don't tell me you've never done a = b when you meant a == b. Everyone does it! That and leaving out a semicolon once in a while. Yes, compiler warnings can be quite annoying, but they also help uncover a lot of bugs that would otherwise be overlooked. -Craig

I don't like the compiler second-guessing all of the code I write. I don't want it nagging me with every "questionable practice". I like how the Overview to the D spec puts it ... No Warnings D compilers will not generate warnings for questionable code. Code will either be acceptable to the compiler or it will not be. This will eliminate any debate about which warnings are valid errors and which are not, and any debate about what to do with them. The need for compiler warnings is symptomatic of poor language design. (http://www.digitalmars.com/d/overview.html) jcc7
Feb 22 2005
parent reply Derek <derek psych.ward> writes:
On Tue, 22 Feb 2005 18:38:04 +0000 (UTC), J C Calvarese wrote:

 In article <cvfn4j$i35$1 digitaldaemon.com>, Craig Black says...
"zwang" <nehzgnaw gmail.com> wrote in message 
news:cve3ru$1crf$1 digitaldaemon.com...
 Derek Parnell wrote:
 I found a mistake in my code today that I was surprised that DMD didn't
 mark as an error.

 It went something like ...

 # void main() # {
 #    long x,y;    #    x == y;
 #}

 In other words, the "x == y;" is a no-operation. I had meant to write "x 
 =
 y;" but accidentally added the extra '='.

 As DMD is anxious to catch the "if (a = b)" type mistakes, I just assumed
 it would mark other potentially silly mistakes too. But maybe there is a 
 good reason for it not to ... side-effects maybe?

IMO, no-op checking is the responsibility of a lint program rather than the compiler's. I actually hope DMD could be less fastidious, for example, implicitly converts integer to boolean so that I can write "if (a = b)" statements without being nagged.

That would be nice if you like bugs in your code. And don't tell me you've never done a = b when you meant a == b. Everyone does it! That and leaving out a semicolon once in a while. Yes, compiler warnings can be quite annoying, but they also help uncover a lot of bugs that would otherwise be overlooked. -Craig

I don't like the compiler second-guessing all of the code I write. I don't want it nagging me with every "questionable practice". I like how the Overview to the D spec puts it ... No Warnings D compilers will not generate warnings for questionable code. Code will either be acceptable to the compiler or it will not be. This will eliminate any debate about which warnings are valid errors and which are not, and any debate about what to do with them. The need for compiler warnings is symptomatic of poor language design. (http://www.digitalmars.com/d/overview.html) jcc7

So how about something like ... warnings(1){ . . . } Where inside the 'warnings' block, the compiler will bother to tell us of questionable acts, for those of us who enjoy having some help from our tools. This would not be the default and thus one would have to explicitly turn on the feature. This is similar in concept to the 'debug{}' sections of code. Though maybe there could also be a 'warnings(){}' block in which there would be no warnings generated, this way we could have some sections *inside* a warnings block excluded. -- Derek Melbourne, Australia
Feb 22 2005
parent J C Calvarese <jcc7 cox.net> writes:
In article <8j06qh3hsnld.1qto19n9fp7gz.dlg 40tude.net>, Derek says...

..
So how about something like ...

  warnings(1){
      . . .
  }

Where inside the 'warnings' block, the compiler will bother to tell us of
questionable acts, for those of us who enjoy having some help from our
tools. This would not be the default and thus one would have to explicitly
turn on the feature. This is similar in concept to the 'debug{}' sections
of code. Though maybe there could also be a 'warnings(){}' block in which
there would be no warnings generated, this way we could have some sections
*inside* a warnings block excluded.

I'm not really against this, but I think the best situation would be to either have a separate program to do these checks (e.g. lint) or have an optional compiler flag (that would be "off" by default).
-- 
Derek
Melbourne, Australia

jcc7
Feb 22 2005
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Derek Parnell wrote:
 I found a mistake in my code today that I was surprised that DMD didn't
 mark as an error.
 
 It went something like ...
 
 # void main() 
 # {
 #    long x,y;    
 #    x == y;
 #}
 
 In other words, the "x == y;" is a no-operation. I had meant to write "x =
 y;" but accidentally added the extra '='.
 
 As DMD is anxious to catch the "if (a = b)" type mistakes, I just assumed
 it would mark other potentially silly mistakes too. 
 
 But maybe there is a good reason for it not to ... side-effects maybe?
 

I believe that D is supposed to pick up this kind of statement. This doesn't mean that it's doing it yet. (Remember, we are still considerably(?) shy of version 1.0.) My impression is that somewhere in the D specs it says that null statements are generally illegal. (Meaning, e.g., excess semicolons, but stated in a way that would include the error that you generated, also.)
Feb 23 2005
parent reply Paul Bonser <misterpib gmail.com> writes:
Charles Hixson wrote:
 Derek Parnell wrote:
 
 I found a mistake in my code today that I was surprised that DMD didn't
 mark as an error.

 It went something like ...

 # void main() # {
 #    long x,y;    #    x == y;
 #}

 In other words, the "x == y;" is a no-operation. I had meant to write 
 "x =
 y;" but accidentally added the extra '='.

 As DMD is anxious to catch the "if (a = b)" type mistakes, I just assumed
 it would mark other potentially silly mistakes too.
 But maybe there is a good reason for it not to ... side-effects maybe?

I believe that D is supposed to pick up this kind of statement. This doesn't mean that it's doing it yet. (Remember, we are still considerably(?) shy of version 1.0.) My impression is that somewhere in the D specs it says that null statements are generally illegal. (Meaning, e.g., excess semicolons, but stated in a way that would include the error that you generated, also.)

"Expressions that have no affect[sic], like (x+x), are illegal in expression statements." Also, the word should be effect. English is about the only thing that was actually taught well at my hich school. ;) -- -PIB -- "C++ also supports the notion of *friends*: cooperative classes that are permitted to see each other's private parts." - Grady Booch
Feb 24 2005
parent Charles Hixson <charleshixsn earthlink.net> writes:
Paul Bonser wrote:
 Charles Hixson wrote:
 
 Derek Parnell wrote:

 I found a mistake in my code today that I was surprised that DMD didn't
 mark as an error.

 It went something like ...

 # void main() # {
 #    long x,y;    #    x == y;
 #}

 In other words, the "x == y;" is a no-operation. I had meant to write 
 "x =
 y;" but accidentally added the extra '='.



statement. This
 doesn't mean that it's doing it yet.  (Remember, we are still 
 considerably(?) shy of version 1.0.)

 My impression is that somewhere in the D specs it says that null 
 statements are generally illegal.  (Meaning, e.g., excess semicolons, 
 but stated in a way that would include the error that you generated, 
 also.)

"Expressions that have no affect[sic], like (x+x), are illegal in expression statements." Also, the word should be effect. English is about the only thing that was actually taught well at my hich school. ;)

covered. (I feel it *ought* to be, though. But since there is no assignment, perhaps it *is* covered. Still, I guess that this wording allows extra semi-colons.)
Feb 25 2005