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

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.

"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

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

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

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

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

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

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 '='.
...>> 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. ;)
> 
O.  But then since this was a statement(?), perhaps it isn't 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.)