• John C (13/13) Dec 05 2005 I turned on warnings for the first time tonight, and have uncovered
• Kris (5/19) Dec 05 2005 The warning is annoying since, as you point out, the language design cau...
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (5/8) Dec 06 2005 Back in the day Walter didn't use warnings for Phobos, even.
• BSC (11/24) Dec 05 2005 from docs:
• John C (5/41) Dec 05 2005 Yes, I was aware of those definitions. Surely they have nothing to do wi...
• John Demme (11/27) Dec 05 2005 The reason for this is that it's frequently faster to return an int than...
• Raffles munchgreeble xxATxx bigfoot xxDOTxx com (12/46) Dec 06 2005 Given D's aim for speed, I think using an int is fine - in fact I
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (4/7) Dec 06 2005 As long as it isn't returning something that makes logical sense,
• Lionello Lunesu (4/10) Dec 06 2005 That's why "bool" should actually be an alias for "int", not for bit...

"John C" <johnch_atms hotmail.com> writes:

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" <fu bar.com> writes:

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
 

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

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

BSC <BSC_member pathlink.com> writes:

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 

"John C" <johnch_atms hotmail.com> writes:

"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

 

John Demme <me teqdruid.com> writes:

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

Raffles munchgreeble xxATxx bigfoot xxDOTxx com <"a" b.com> writes:

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

 
 

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

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

"Lionello Lunesu" <lio remove.lunesu.com> writes:

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