digitalmars.D - Bool: I surrender
- Arcane Jill (17/17) Jun 03 2004 I give in. I'm doing the decent thing and returning "bool" everythere in...
- Walter (10/15) Jun 04 2004 objects.
- Arcane Jill (8/8) Jun 04 2004 Tell me, if n is an int, what does (cast(bool)n) do, exactly?
- Ilya Minkov (5/8) Jun 04 2004 Casting integer to bool returns false for 0, otherwise it returns true, ...
- Walter (3/4) Jun 04 2004 n?1:0
- Norbert Nemec (11/18) Jun 07 2004 Now, this seems like a language inconsistency to me: if bit is supposed ...
- Ilya Minkov (12/22) Jun 04 2004 Is there any chance that you change that to bit, and make a compiler
- J Anderson (15/36) Jun 04 2004 I'd make that
- Sean Kelly (12/12) Jun 07 2004 FWIW, I totally changed my stance on the "bool" issue this morning. I r...
- J C Calvarese (10/24) Jun 07 2004 I also fail to see the advantage of the bool alias. It seems
- J Anderson (7/14) Jun 07 2004 Yeah, it seems strange. I guess it makes porting easier but we could
- J C Calvarese (5/23) Jun 07 2004 That's kind of what I'm hoping and/or afraid of.
- James McComb (6/12) Jun 07 2004 It looks like D will be stuck with the problem of some people using bit
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
"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 allobjects.Now we are seeing platform-dependent behavior because of this. It reallyshouldbe 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,pleasecould 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
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
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
"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
Walter wrote:"Arcane Jill" <Arcane_member pathlink.com> wrote in message news:c9p965$2kcb$1 digitaldaemon.com...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... :-)Tell me, if n is an int, what does (cast(bool)n) do, exactly?n?1:0
Jun 07 2004
Walter schrieb: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? -eyebe 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.
Jun 04 2004
Ilya Minkov wrote:Walter schrieb: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/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?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.
Jun 04 2004
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
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. SeanI 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
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
J Anderson wrote:J C Calvarese wrote:That's kind of what I'm hoping and/or afraid of. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/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.
Jun 07 2004
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