I turned on warnings for the first time tonight, and have uncovered something quite weird, which is that '==' appears to evaluate to an 'int', not 'bit'. But hang on, isn't 'bit' D's boolean type (or rather, the nearest to it)? And 'true' and 'false' are of type bit. And 'bool' in object.d is an alias for bit. So why on earth does the compiler expect the result of an equality test to be an int?

I don't want to start another unproductive debate on the whys and wherefores of not having a built-in bool, but this seems topsy-turvey.

bit testEquality(int a, int b) {
    return a == b;
}

warning - implicit conversion of expression (a == b) of type int to bit can cause loss of data

The warning is annoying since, as you point out, the language design causes a sea of false-positives to be produced. This particular concern was posted the very day -w came into being, but nothing came of that ...


"John C" <johnch_atms@hotmail.com> wrote in message news:dn2ljn$2jgi$1@digitaldaemon.com...
>I turned on warnings for the first time tonight, and have uncovered something quite weird, which is that '==' appears to evaluate to an 'int', not 'bit'. But hang on, isn't 'bit' D's boolean type (or rather, the nearest to it)? And 'true' and 'false' are of type bit. And 'bool' in object.d is an alias for bit. So why on earth does the compiler expect the result of an equality test to be an int?
>
> I don't want to start another unproductive debate on the whys and wherefores of not having a built-in bool, but this seems topsy-turvey.
>
> bit testEquality(int a, int b) {
>    return a == b;
> }
>
> warning - implicit conversion of expression (a == b) of type int to bit can cause loss of data
> 

from docs:
<stuff>
The member function opEquals() is defined as part of Object as:

int opEquals(Object o);

..

The member function opCmp() is defined as part of Object as:

int opCmp(Object o);
</stuff>

The second case may be the reason behind all that. For what it's worth, I also think it's odd.



In article <dn2ljn$2jgi$1@digitaldaemon.com>, John C says...
>
>I turned on warnings for the first time tonight, and have uncovered something quite weird, which is that '==' appears to evaluate to an 'int', not 'bit'. But hang on, isn't 'bit' D's boolean type (or rather, the nearest to it)? And 'true' and 'false' are of type bit. And 'bool' in object.d is an alias for bit. So why on earth does the compiler expect the result of an equality test to be an int?
>
>I don't want to start another unproductive debate on the whys and wherefores of not having a built-in bool, but this seems topsy-turvey.
>
>bit testEquality(int a, int b) {
>    return a == b;
>}
>
>warning - implicit conversion of expression (a == b) of type int to bit can cause loss of data
>
>

"BSC" <BSC_member@pathlink.com> wrote in message news:dn2oq2$2me5$1@digitaldaemon.com...
> from docs:
> <stuff>
> The member function opEquals() is defined as part of Object as:
>
> int opEquals(Object o);
>
> ..
>
> The member function opCmp() is defined as part of Object as:
>
> int opCmp(Object o);
> </stuff>
>
> The second case may be the reason behind all that. For what it's worth, I
> also
> think it's odd.

Yes, I was aware of those definitions. Surely they have nothing to do with non-class methods, though. Even if they did, are you saying opCmp gets called for == ?

>
>
>
> In article <dn2ljn$2jgi$1@digitaldaemon.com>, John C says...
>>
>>I turned on warnings for the first time tonight, and have uncovered
>>something quite weird, which is that '==' appears to evaluate to an 'int',
>>not 'bit'. But hang on, isn't 'bit' D's boolean type (or rather, the
>>nearest
>>to it)? And 'true' and 'false' are of type bit. And 'bool' in object.d is
>>an
>>alias for bit. So why on earth does the compiler expect the result of an
>>equality test to be an int?
>>
>>I don't want to start another unproductive debate on the whys and
>>wherefores
>>of not having a built-in bool, but this seems topsy-turvey.
>>
>>bit testEquality(int a, int b) {
>>    return a == b;
>>}
>>
>>warning - implicit conversion of expression (a == b) of type int to bit
>>can
>>cause loss of data
>>
>>
>
> 

The reason for this is that it's frequently faster to return an int than a bit.  Why?  Because there are very few operations that actually return a bit (unless then have a "return true" or "return false" in them) and it takes time to cast from an int to a bit.  For instance, if I want to test if one uint is equal to another (without using the builtin ==) then I just subtract one from the other, and return it- no casting to bit.

Personally, I'd prefer to use bit as it makes MUCH more logical sense, but Walter disagrees.  And as far as quirks and such go, this is a fairly minor one IMHO.

~John Demme

John C wrote:

> I turned on warnings for the first time tonight, and have uncovered something quite weird, which is that '==' appears to evaluate to an 'int', not 'bit'. But hang on, isn't 'bit' D's boolean type (or rather, the nearest to it)? And 'true' and 'false' are of type bit. And 'bool' in object.d is an alias for bit. So why on earth does the compiler expect the result of an equality test to be an int?
> 
> I don't want to start another unproductive debate on the whys and wherefores of not having a built-in bool, but this seems topsy-turvey.
> 
> bit testEquality(int a, int b) {
>     return a == b;
> }
> 
> warning - implicit conversion of expression (a == b) of type int to bit
> can cause loss of data

Given D's aim for speed, I think using an int is fine - in fact I wouldn't want it to use a slower type - however I agree that at the source code level I want to see the abstraction that the language presents, not what's going on under the hood to make my code run like greased lightning, certainly getting warnings about this is bad (IMHO).

However for me it's the kind of thing that's easy to put up with whilst the language is still under development - I think polishing this kind of thing can wait until the features are all complete. There are other niggles like this, but sorting them out can wait!

Just my tuppence.

Munch

John Demme wrote:
> The reason for this is that it's frequently faster to return an int than a
> bit.  Why?  Because there are very few operations that actually return a
> bit (unless then have a "return true" or "return false" in them) and it
> takes time to cast from an int to a bit.  For instance, if I want to test
> if one uint is equal to another (without using the builtin ==) then I just
> subtract one from the other, and return it- no casting to bit.
> 
> Personally, I'd prefer to use bit as it makes MUCH more logical sense, but
> Walter disagrees.  And as far as quirks and such go, this is a fairly minor
> one IMHO.
> 
> ~John Demme
> 
> John C wrote:
> 
> 
>>I turned on warnings for the first time tonight, and have uncovered
>>something quite weird, which is that '==' appears to evaluate to an 'int',
>>not 'bit'. But hang on, isn't 'bit' D's boolean type (or rather, the
>>nearest to it)? And 'true' and 'false' are of type bit. And 'bool' in
>>object.d is an alias for bit. So why on earth does the compiler expect the
>>result of an equality test to be an int?
>>
>>I don't want to start another unproductive debate on the whys and
>>wherefores of not having a built-in bool, but this seems topsy-turvey.
>>
>>bit testEquality(int a, int b) {
>>    return a == b;
>>}
>>
>>warning - implicit conversion of expression (a == b) of type int to bit
>>can cause loss of data
> 
> 

Kris wrote:

> The warning is annoying since, as you point out, the language design causes a sea of false-positives to be produced. This particular concern was posted the very day -w came into being, but nothing came of that ...

Back in the day Walter didn't use warnings for Phobos, even.
(so you got plenty of such warnings, to silence with casts...)

Haven't tested with DMD 0.140, though. Does it compile with -w ?

--anders

John Demme wrote:

> Personally, I'd prefer to use bit as it makes MUCH more logical sense, but
> Walter disagrees.  And as far as quirks and such go, this is a fairly minor
> one IMHO.

As long as it isn't returning something that makes logical sense,
like "bool", then I for one don't care if it's using int or bit...

--anders

"John Demme" <me@teqdruid.com> wrote in message news:dn31l8$2t3e$1@digitaldaemon.com...
> The reason for this is that it's frequently faster to return an int than a bit.  Why?  Because there are very few operations that actually return a bit (unless then have a "return true" or "return false" in them) and it takes time to cast from an int to a bit.  For instance, if I want to test if one uint is equal to another (without using the builtin ==) then I just subtract one from the other, and return it- no casting to bit.

That's why "bool" should actually be an alias for "int", not for bit...

L.