www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - if(bool = x) does not give a boolean result

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
I have code like this in dcollections:


     /**
      * Removes the element that has the given key.  Sets wasRemoved to  
true if the
      * element was present and was removed.
      *
      * Runs on average in O(1) time.
      */
     HashMap remove(K key, out bool wasRemoved)
     {
         cursor it = elemAt(key);
         if(wasRemoved = !it.empty)
         {
             remove(it);
         }
         return this;
     }


However, this does not compile with the following message:

dcollections/HashMap.d(561): Error: '=' does not give a boolean result

line 561 is the if statement.

Since when did bool = bool not give a bool result?

Do I have to write it out like this:

if((wasRemoved = !it.empty) == true)

I can understand for ints and strings and whatnot, but for booleans?

-Steve
May 07 2010
next sibling parent Graham Fawcett <fawcett uwindsor.ca> writes:
On Fri, 07 May 2010 07:56:23 -0400, Steven Schveighoffer wrote:

 I have code like this in dcollections:
 
 
      /**
       * Removes the element that has the given key.  Sets wasRemoved to
 true if the
       * element was present and was removed. *
       * Runs on average in O(1) time.
       */
      HashMap remove(K key, out bool wasRemoved) {
          cursor it = elemAt(key);
          if(wasRemoved = !it.empty)
          {
              remove(it);
          }
          return this;
      }
 
 
 However, this does not compile with the following message:
 
 dcollections/HashMap.d(561): Error: '=' does not give a boolean result
 
 line 561 is the if statement.
 
 Since when did bool = bool not give a bool result?

Don't you mean bool == bool, not bool = bool? Graham
May 07 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 07 May 2010 08:02:00 -0400, Graham Fawcett <fawcett uwindsor.ca>  
wrote:

 On Fri, 07 May 2010 07:56:23 -0400, Steven Schveighoffer wrote:

 I have code like this in dcollections:


      /**
       * Removes the element that has the given key.  Sets wasRemoved to
 true if the
       * element was present and was removed. *
       * Runs on average in O(1) time.
       */
      HashMap remove(K key, out bool wasRemoved) {
          cursor it = elemAt(key);
          if(wasRemoved = !it.empty)
          {
              remove(it);
          }
          return this;
      }


 However, this does not compile with the following message:

 dcollections/HashMap.d(561): Error: '=' does not give a boolean result

 line 561 is the if statement.

 Since when did bool = bool not give a bool result?

Don't you mean bool == bool, not bool = bool?

No. I meant bool = bool. I'm not comparing two bools, I'm assigning to a bool, and then using if on the result. At best, this is a bogus error message. -Steve
May 07 2010
parent BCS <none anon.com> writes:
Hello Steven,

 No.  I meant bool = bool.  I'm not comparing two bools, I'm assigning
 to a  bool, and then using if on the result.  At best, this is a bogus
 error  message.
 

More often than not (or so the thinking goes), that isn't the case and the programmer in fact did want ==. Also, you might check if "if((var = boolExp))" works. -- ... <IXOYE><
May 08 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 I have code like this in dcollections:

This is similar code that shows the same thing: import std.stdio; void main() { bool b = true; bool c; if (c = !b) writeln("****"); }
 Since when did bool = bool not give a bool result?

I guess since Walter has decided to avoid in D the common bug present in C and C++ programs caused by using = instead of == inside an if(). For the exactly the same bug-avoidance purpose, Python too allows chained assigns: a = b = 10 but it refuses the assign in the if: if x = 10: ...
 Do I have to write it out like this:
 if((wasRemoved = !it.empty) == true)

Yep. Or you can write it like this, also gaining readability as side-effect: wasRemoved = !it.empty if (wasRemoved) { ... In other situations you can write code like this in D: if (bool c = !b) A bit of less syntactic convenience is a price worth paying for a reduced bug-prone language that wants to keep the flavour of upwards compatibility to C that D wants.
 I can understand for ints and strings and whatnot, but for booleans?

My guess: that's a special case. Special cases kill languages (see C++), so better to have no exceptions. Less things to remember, simpler compiler, shorter books about D, less time to read the language. Bye, bearophile
May 07 2010
parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
bearophile wrote:

 Steven Schveighoffer:
 
 I have code like this in dcollections:

This is similar code that shows the same thing: import std.stdio; void main() { bool b = true; bool c; if (c = !b) writeln("****"); }
 Since when did bool = bool not give a bool result?

I guess since Walter has decided to avoid in D the common bug present in C and C++ programs caused by using = instead of == inside an if(). For the exactly the same bug-avoidance purpose, Python too allows chained assigns: a = b = 10 but it refuses the assign in the if: if x = 10: ...
 Do I have to write it out like this:
 if((wasRemoved = !it.empty) == true)

Yep. Or you can write it like this, also gaining readability as side-effect: wasRemoved = !it.empty if (wasRemoved) { ... In other situations you can write code like this in D: if (bool c = !b) A bit of less syntactic convenience is a price worth paying for a reduced bug-prone language that wants to keep the flavour of upwards compatibility to C that D wants.
 I can understand for ints and strings and whatnot, but for booleans?

My guess: that's a special case. Special cases kill languages (see C++), so better to have no exceptions. Less things to remember, simpler compiler, shorter books about D, less time to read the language. Bye, bearophile

This is all true but if this is how the feature should be defined I think the error message should improve. Something along the lines of, "Assignments not allowed as thruth values in conditional statments" seems more clear.
May 07 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 07 May 2010 14:42:15 -0400, Johan Granberg  
<lijat.meREM ovegmail.com> wrote:


 This is all true but if this is how the feature should be defined I think
 the error message should improve. Something along the lines
 of, "Assignments not allowed as thruth values in conditional statments"
 seems more clear.

http://d.puremagic.com/issues/show_bug.cgi?id=4163 Feel free to add suggestions for the correct error message. It was indeed the error message that had me puzzled as to whether it should be allowed or not. -Steve
May 07 2010