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

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

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

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

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.

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

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