> The D options are:
>
> 1) use bit which has only 'true' or 'false' values
> 2) use int which has !0 and 0 values (the C style)
> 3) use bool for those who don't think that bit is self-documenting <g>

Could a fourth option be the development of a boolean type ("boolean" ?) that is packaged with Phobos, that is not implicitly convertible, disallows arithmetic operations, etc? What would be needed in the language to do so? Is it already in D (opCast, making arithemetic operators private)? I remember in CUJ reading an article Herb Sutter wrote (I think) about the "nullptr" keyword proposal, and it mentioned that several library based solutions were tried before proposing a new keyword. Maybe such a type could be a "proof-of-concept".

<opinion> "bool" being an alias for bit seems to open the way for implementation-defined quirks to pop up. Same with int. The programmer shouldn't need to worry about implementation issues (or how badly his fellow coder/coworker can stretch the rules) for what seems to be such a narrowly-defined logical type. </opinion>

(Could be 100% off-base here... don't flame too hard. Just my $0.02)

Les Baker

In article <c9lrlu$k74$1@digitaldaemon.com>, Walter says...
>

>A 'bit' by itself has a size of 1 byte. Only when turned into an array are they packed into bit positions in memory.

Can I just add at this point that in all my life, I have never seen an array of boolean truth values.

An array of bits, yes, but an array of bools? I'm not suggesting that such an animal is fantasy, but it's rare enough to be considered an endangered species <g>. I don't think the language need worry about this. If some programmer wants to bit-pack bools then they can always cast them to bits first.

Jill

PS. I've given up debating about whether or not there should be a separate bool type, and simply written one. My only remaining concern now is the opEquals() should return a bool - regardless of what bool is aliased to.

"Derek Parnell" <derek@psych.ward> wrote in message news:c9m71a$149k$1@digitaldaemon.com...
> > Of course, these can all be uglified with cast(int)b, or with (b?1:0),
> "uglified"? One person's "ugly" is another person "documentation" ;-)

I'll have you know I have just patented "uglified" and y'all owe me royalties!


> I prefer writing code that other people can easily read, so that they can
> understand my intentions. Brevity, for its own sake, does not guarentee
> legibilty.
> I would always prefer clearest code over fastest code.

And of course, I think the way I wrote it is clearer <g>.

In article <c9mbn7$1c1u$1@digitaldaemon.com>, Les Baker says...
>
>> The D options are:
>>
>> 1) use bit which has only 'true' or 'false' values
>> 2) use int which has !0 and 0 values (the C style)
>> 3) use bool for those who don't think that bit is self-documenting <g>
>
>Could a fourth option be the development of a boolean type ("boolean" ?) that is packaged with Phobos, that is not implicitly convertible, disallows arithmetic operations, etc?

Done it. The type is called Bool.

>What would be needed in the language to do so?

import etc.workaround.types;

>Is it already in D (opCast, making arithemetic operators private)?

It's in Deimos.

>remember in CUJ reading an article Herb Sutter wrote (I think) about the "nullptr" keyword proposal, and it mentioned that several library based solutions were tried before proposing a new keyword. Maybe such a type could be a "proof-of-concept".

Feel free to try it out. All of the boolean operations in the Int class now use Bool instead of bool, boolean or int. Bools will *not* auto-convert either to or from ints, but they can be used in flow-control statements like if (b)...

Code is at http://www.fast-forward.info/ramonsky/stuff/d/bigint.html. This includes the Bool type.

Arcane Jill


PS.

><opinion> "bool" being an alias for bit seems to open the way for implementation-defined quirks to pop up. Same with int. The programmer shouldn't need to worry about implementation issues (or how badly his fellow coder/coworker can stretch the rules) for what seems to be such a narrowly-defined logical type. </opinion>

I don't care whether D's bool is aliased to bool or to int. I do care that the value returned by D's opEquals() does not auto-cast to D's bool.

Arcane Jill wrote:

> Can I just add at this point that in all my life, I have never seen an array of boolean truth values.

This can also be interpreted as another indicator that the semantic distinction between bit and bool is rather blurred. Where is the semantic difference between a bitmask and an array of boolean values?

Of course, there are many clear cases, where you can clearly say "This is a bool" or "This has to be a bit" - but there also is a huge grey area.

Especially when working with array expressions (vectorized), it is very often extremely common to do arithmetics that interpret a bool field as a field with the values 0 or 1.

On modern, pipelining processors, in many cases, it even is more efficient to have a floating point multiplication with either 0.0 or 1.0 than doing conditional statements since the latter may break the pipeline. Of course, an intelligent compiler might do something like this as optimization, but for that to work, D would probably have to be tailored a lot more towards vectorized expressions (i.e. array expressions)

>       int main()
>       {
>           bit b = 1;
>           ++b;
>           printf("%d\n", b);
>           return 0;
>       }

Prints 2.
Jill

We'll just agree to disagree, then.

In article <c9kd4u$1h85$1@digitaldaemon.com>, hellcatv@hotmail.com says...
>
>while I agree that bool is ambiguous I think most people would prefer it aliased
>to int rather than bit in object.d :-)
>can we override it in a general sense so it will compile elsewhere? (i.e. alias
>int bool; and not have conflicts with the bit bool in the object.d  ... also the
>last thing I would want is to have problems like libjpeg of bool being char
>somewhere and int otherwhere and bit thirdware)

OK, so now officially starts the D bool nightmare.
Having fought for 10+ years with the C bool nightmare, I admit I'm not happy.

Once I spent a week or so trying to get 3 different kind of bool, Bool and BOOL
work with the various true, True, TRUE, false, False, FALSE and whatever.
The fact that programmers kept writing

if (expr == True/TRUE/false...)

was another source for bugs.

For me it's astonishing that experienced C programmers think that having a true bool type is not useful. Most of the library I've seen defined their own kind of boolean type (when you're lucky it's 'typedef int', but I've also seen ' #define char', or 'void *'), and unaware programmers did the rest of the work.

I pray for a boolean type, whatever the implementation, giving all D programs and libraries consistency.

Ciao

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9miu4$1mak$1@digitaldaemon.com...
>
> >       int main()
> >       {
> >           bit b = 1;
> >           ++b;
> >           printf("%d\n", b);
> >           return 0;
> >       }
>
> Prints 2.
> Jill

That's a bug.

All this just goes to show that bit are cleaner to read as they are now.

Derek Parnell wrote:

>On Wed, 2 Jun 2004 20:00:26 -0700, Walter wrote:
>
>  
>
>>"Derek Parnell" <derek@psych.ward> wrote in message
>>news:c9m1v3$sv4$1@digitaldaemon.com...
>>    
>>
>>>>- but regarding
>>>>the principle that a bool is not arithmetic, if you have been following
>>>>        
>>>>
>>this
>>    
>>
>>>>forum, you'll know you are in a very small minority here.
>>>>        
>>>>
>>>void main( )
>>>{
>>>    char[] myHat = "red";
>>>    char[] myCoat = "blue";
>>>    bool a = (myHat == "red");
>>>    bool b = (myCoat == "blue");
>>>    int  c;
>>>
>>>    c = (3*a) + (b*b);
>>>
>>>    printf("%d %d %d\n",a,b,c);
>>>}
>>>
>>>
>>>LOL!!!! Why this code above should compile is beyond my understanding. In
>>>English it is like saying "Q:What is the sum of three times (is my hat
>>>red?) and the square of (is my coat blue?)?  A: 4!"
>>>      
>>>
>>Here are some uses that I use now and then:
>>--------------------------------
>>1) Assembling a 'flags variable' from boolean components:
>>
>>    bool Carry;
>>    bool Overflow;
>>    uint flags = (Carry << 6) | Overflow;
>>    
>>
>
>And I would have coded it more explicitly...
>
>      uint flags = (Carry ? 1<<6 : 0) | (Overflow? 1 : 0);
>
>or maybe even ...
>
>      flags = 0;           if (Carry )
>          flags |= 1<<6;
>      if (Overflow)
>          flags |= 1;
>
>
>  
>
>>2) Add booleans to state variable to, for example, conditionally advance to
>>the next state in a state machine:
>>
>>    state += (foo == bar);
>>    
>>
>
>Not explict enough for my 'self-documenting code' standards.
>
>      if (foo == bar)
>          state += 1;
> 
>  
>
>>3) Use bools as an index into an array:
>>
>>char[] response[2];
>>printf("answer is %.*s\n", response[ foo == bar ]);
>>    
>>
>
>  printf("answer is %.*s\n", response[ (foo == bar ? 0 : 1) ]);
>
>or 
>
>  char[] response[2];
>  char[] msg;
>
>  // Because one day there might be more than two potential messages.
>  switch (foo)
>  {
>    case foo:
>        msg = response[0];
>        break;
>    default:
>        msg = response[1];
>  };
>  printf("answer is %.*s\n", msg);
>
>   
>
>>------------------------------------
>>Of course, these can all be uglified with cast(int)b, or with (b?1:0),
>>    
>>
>
>"uglified"? One person's "ugly" is another person "documentation" ;-)
>
>  
>
>>but I just don't see the paradigm problem with bool being a 1 or a 0 integer.
>>    
>>
>
>True, its just a way of thinking. A metaphor, if you will.
>
>I prefer writing code that other people can easily read, so that they can
>understand my intentions. Brevity, for its own sake, does not guarentee
>legibilty.
>
>I would always prefer clearest code over fastest code.
>
>  
>


-- 
-Anderson: http://badmama.com.au/~anderson/