www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bool: I surrender

reply Arcane Jill <Arcane_member pathlink.com> writes:
I give in. I'm doing the decent thing and returning "bool" everythere instead of
"Bool" - not because I think Walter's got it right, but because conflicting
standards are no good for anyone. I really *do* believe that, one day in the
future, when standards committees define what D should or should not do, "bool"
itself will be made typesafe, and that transition will of course be easier if we
all (or at least, all public APIs) use the same keyword.

Currently, however, there will have to be one exception (bah!). The exception is
opEquals(), which is defined in object.d to return an int. This is still BAD ...
as Daniel Horn discovered the other day. It seems that on Linux, == sometimes
returns a value other than 0 or 1. This could never have happened if opEquals
had been defined to return (Walter's) bool (that is, aliased to bit).

Please, please, please could opEquals() return bool, not int, for all objects.
Now we are seeing platform-dependent behavior because of this. It really should
be fixed. I can't imagine why opEquals() would want to return an int. I'm
assuming it was a mistake, but Walter, if there's a good reason for it, please
could you clarify for me what that reason is?

Arcane Jill
Jun 03 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9p65n$2e8e$1 digitaldaemon.com...
 Please, please, please could opEquals() return bool, not int, for all

 Now we are seeing platform-dependent behavior because of this. It really

 be fixed. I can't imagine why opEquals() would want to return an int. I'm
 assuming it was a mistake, but Walter, if there's a good reason for it,

 could you clarify for me what that reason is?

The reason is runtime efficiency, as described in my reply to your posting "Efficiency test for various boolean strategies." opEquals() has the potential to be a huge performance bottleneck for sorting and searching algorithms, so defining it so it can be implemented as efficiently as possible is important.
Jun 04 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
Tell me, if n is an int, what does (cast(bool)n) do, exactly?

Does it do (n & 1), in the same way that (cast(ubyte)n) does (n & 0xFF)? Or does
it do (n==0 ? 0 : 1). In other words, does it truncate like ints, or saturate
like floats?

I haven't seen a definition anywhere, and if opEquals() is allowed to return
non-0, non-1 values (even by accident) it would be useful to know that casting
to bool is always going to do the right thing.

Jill
Jun 04 2004
next sibling parent Ilya Minkov <Ilya_member pathlink.com> writes:
In article <c9p965$2kcb$1 digitaldaemon.com>, Arcane Jill says...

I haven't seen a definition anywhere, and if opEquals() is allowed to return
non-0, non-1 values (even by accident) it would be useful to know that casting
to bool is always going to do the right thing.

Casting integer to bool returns false for 0, otherwise it returns true, to be consistent with C semantics. Same convention applies when short-cut operators are executed on integers. -eye
Jun 04 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9p965$2kcb$1 digitaldaemon.com...
 Tell me, if n is an int, what does (cast(bool)n) do, exactly?

n?1:0
Jun 04 2004
parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Walter wrote:

 
 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:c9p965$2kcb$1 digitaldaemon.com...
 Tell me, if n is an int, what does (cast(bool)n) do, exactly?

n?1:0

Now, this seems like a language inconsistency to me: if bit is supposed to be an integer type of length one bit, then it should actually cast like the other integer types, i.e. by masking the original value. if (cast(ubyte)n) == (n & 0xff) then I would expect (cast(bit)n) == (n & 0x01) Of course, this would have little practical use. Oh, well - guess that's just once again the good old thing about bool vs. bit... :-)
Jun 07 2004
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Walter schrieb:

be fixed. I can't imagine why opEquals() would want to return an int. I'm
assuming it was a mistake, but Walter, if there's a good reason for it, please
could you clarify for me what that reason is?

The reason is runtime efficiency, as described in my reply to your posting "Efficiency test for various boolean strategies." opEquals() has the potential to be a huge performance bottleneck for sorting and searching algorithms, so defining it so it can be implemented as efficiently as possible is important.

Is there any chance that you change that to bit, and make a compiler provosion that would e.g. always hand bit as int when it is used as a return value to a back end? Perhaps bit should always be stored in an int storage instead of a byte storage, except for within structs and as bit arrays, where multiple adjacent bits would complement each other to bytes? Wasn't it your argumentation that code should follow principles of expressiveness, and it's compiler's work to take care of efficiency? I'm not sure where the storage size becomes relevant to performance. If i remember correctly from fog's pentopt, on modern processors mostly alignment is important. Is there anything else causing the penalty? -eye
Jun 04 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Ilya Minkov wrote:

 Walter schrieb:

 be fixed. I can't imagine why opEquals() would want to return an 
 int. I'm
 assuming it was a mistake, but Walter, if there's a good reason for 
 it, please
 could you clarify for me what that reason is?

The reason is runtime efficiency, as described in my reply to your posting "Efficiency test for various boolean strategies." opEquals() has the potential to be a huge performance bottleneck for sorting and searching algorithms, so defining it so it can be implemented as efficiently as possible is important.

Is there any chance that you change that to bit, and make a compiler provosion that would e.g. always hand bit as int when it is used as a return value to a back end? Perhaps bit should always be stored in an int storage instead of a byte storage, except for within structs and as bit arrays, where multiple adjacent bits would complement each other to bytes?

I'd make that except for within structs, multiple function parameters and as bit arrays, I guess the way bit is defined now makes it possible for D vendors to optimise it however they want. Of couse dmd is the major D vendor at the moment and I would hope that dmd will one day include these types of optimisations. I think the more details you provide to the compiler about what you are doing the better it should be able to optimise your code. If you only need a bit, you should use a bit and the compiler should worry about making optimisations on that type. Since the compiler knows that a bit will only ever be on or off, then it should be able to use that to its advantage, not to its determent. -- -Anderson: http://badmama.com.au/~anderson/
Jun 04 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
FWIW, I totally changed my stance on the "bool" issue this morning.  I realized
my complaints were all due to semantics.  To me, "bool" purely describes
behavior, and I've been basing my expectations based on my experience with
C/C++.  "bit," however, is a far more descriptive term.  It describes both
behavior and storage, and is far more clear to me than "bool."  Simply put, I
have no issues at all with the current behavior of the bit datatype.  But if I
had my druthers we'd just do away with the bool alias and make a clean break
with the past... which probably puts me in the minority on this list :)

I do think that Phobos should document its interfaces using "bit" however.
Mixing both terms seems inconsistent and slightly confusing to newcomers, and
invites problems on the off chance that the definition of "bool" ever changes.

Sean
Jun 07 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Sean Kelly wrote:
 FWIW, I totally changed my stance on the "bool" issue this morning.  I realized
 my complaints were all due to semantics.  To me, "bool" purely describes
 behavior, and I've been basing my expectations based on my experience with
 C/C++.  "bit," however, is a far more descriptive term.  It describes both
 behavior and storage, and is far more clear to me than "bool."  Simply put, I
 have no issues at all with the current behavior of the bit datatype.  But if I
 had my druthers we'd just do away with the bool alias and make a clean break
 with the past... which probably puts me in the minority on this list :)
 
 I do think that Phobos should document its interfaces using "bit" however.
 Mixing both terms seems inconsistent and slightly confusing to newcomers, and
 invites problems on the off chance that the definition of "bool" ever changes.
 
 Sean

I also fail to see the advantage of the bool alias. It seems inconsistent with the separation of language and library. Since bit is part of the language, why should we need to call the same thing "bool"? Perhaps bit is a naughty word in someone's culture, but it seems like an invitation to confusion to hide a subtle alias in object.d. (Of course, I'm also in favor of removing printf/wprintf from object.d.) -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jun 07 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
J C Calvarese wrote:

 I also fail to see the advantage of the bool alias. It seems 
 inconsistent with the separation of language and library. Since bit is 
 part of the language, why should we need to call the same thing 
 "bool"? Perhaps bit is a naughty word in someone's culture, but it 
 seems like an invitation to confusion to hide a subtle alias in 
 object.d. (Of course, I'm also in favor of removing printf/wprintf 
 from object.d.)

Yeah, it seems strange. I guess it makes porting easier but we could just as well do a find/replace and learning for beginners. Parhaps Walter plans to pull a fast one on us and switch the bool to some other type when we're not looking. -- -Anderson: http://badmama.com.au/~anderson/
Jun 07 2004
parent J C Calvarese <jcc7 cox.net> writes:
J Anderson wrote:
 J C Calvarese wrote:
 
 I also fail to see the advantage of the bool alias. It seems 
 inconsistent with the separation of language and library. Since bit is 
 part of the language, why should we need to call the same thing 
 "bool"? Perhaps bit is a naughty word in someone's culture, but it 
 seems like an invitation to confusion to hide a subtle alias in 
 object.d. (Of course, I'm also in favor of removing printf/wprintf 
 from object.d.)

Yeah, it seems strange. I guess it makes porting easier but we could just as well do a find/replace and learning for beginners. Parhaps Walter plans to pull a fast one on us and switch the bool to some other type when we're not looking.

That's kind of what I'm hoping and/or afraid of. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jun 07 2004
prev sibling parent James McComb <alan jamesmccomb.id.au> writes:
Sean Kelly wrote:

 ... But if I
 had my druthers we'd just do away with the bool alias and make a clean break
 with the past... which probably puts me in the minority on this list :)

I agree with you. I call it the Just Use Bit view.
 I do think that Phobos should document its interfaces using "bit" however.
 Mixing both terms seems inconsistent and slightly confusing to newcomers, and
 invites problems on the off chance that the definition of "bool" ever changes.

It looks like D will be stuck with the problem of some people using bit and other people using bool with no consistency. Oh well. Maybe Walter should make bool and boolean reserved words? ;) James
Jun 07 2004