> Arcane Jill wrote:
>
> >Personally, I would favor two distinct types: bit and bool, with bit being considered an arithmetic type (like a one bit wide unsigned integer), and bool able only to take values true and false.
> >
> I'm against having two types.  Bit and bool overlap on just about all functionality.  However I do think bit should work for all cases a bool would work.


In what ways do they overlap? bit is a 1-bit integer value, whereas a boolean type is exactly that.

I see no more commonality between them as between a pointer and, on a 32-bit architecture, int.

We very much need a boolean type, otherwise the (IMO) majority of us who want/need one will provide our own (as I have in std.recls, std.windows.registry, etc.) and we'll end up in exactly the same still-stinking mess that C/C++ is in.

Matthew wrote:

>>Arcane Jill wrote:
>>
>>    
>>
>>>Personally, I would favor two distinct types: bit and bool, with bit being
>>>considered an arithmetic type (like a one bit wide unsigned integer), and bool
>>>able only to take values true and false.
>>>
>>>      
>>>
>>I'm against having two types.  Bit and bool overlap on just about all
>>functionality.  However I do think bit should work for all cases a bool
>>would work.
>>    
>>
>
>
>In what ways do they overlap? bit is a 1-bit integer value, whereas a boolean
>type is exactly that.
>  
>
I see a bit as a flag.  It's on or off, true or false. 

bool x;

if (x)
{

}

bit x;

if (x)
{

}

what's the difference between these functions?

bit x = true;

bool x = true;

What's the difference?

bit has more functionality but it still supports all the functionality of bool.

>I see no more commonality between them as between a pointer and, on a 32-bit
>architecture, int.
>
>We very much need a boolean type, otherwise the (IMO) majority of us who
>want/need one will provide our own (as I have in std.recls, std.windows.registry,
>etc.) and we'll end up in exactly the same still-stinking mess that C/C++ is in.
>  
>
Ok I've thought about it a bit more.  Your probably right, as long as bit doesn't loose all the functionality it has now I guess a bool type could be useful as sub-set of bit to prevent users from specifying numbers into functions.

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

Derek Parnell wrote:

> On Mon, 24 May 2004 17:03:11 +0000 (UTC), Arcane Jill wrote:
> 
> [snip]
> 
>> Personally, I would favor two distinct types: bit and bool, with bit being considered an arithmetic type (like a one bit wide unsigned integer), and bool able only to take values true and false. In this scenario, bits could be auto-promoted to int or uint (since those would be widening conversions) but bool could not (because logical types should not auto-convert to arithmetic types).
> 
> 100% agree.
> 
> 'bit' is a very small unsigned integer whose value is in the range 0
> (zero) to 1 (one). And I presume 'sizeof(bit)' should return the number of
> bytes the the implementation uses.
> 
> 'bool' is NOT an integer. It can only have either of two values - TRUE or FALSE. But to make some people's lives a bit easier 'cast(bit)bool' ==> 0 for FALSE and 1 for TRUE.
> 

This is good. I vote for a bool type. Or at least an implicit cast from boolean expressions to bit.

Bruno.

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c8vbnc$jfd$1@digitaldaemon.com...
> Matthew wrote:
>
> >>Arcane Jill wrote:
> >>
> >>
> >>
> >>>Personally, I would favor two distinct types: bit and bool, with bit being considered an arithmetic type (like a one bit wide unsigned integer), and
bool
> >>>able only to take values true and false.
> >>>
> >>>
> >>>
> >>I'm against having two types.  Bit and bool overlap on just about all functionality.  However I do think bit should work for all cases a bool would work.
> >>
> >>
> >
> >
> >In what ways do they overlap? bit is a 1-bit integer value, whereas a boolean type is exactly that.
> >
> >
> I see a bit as a flag.  It's on or off, true or false.
>
> bool x;
>
> if (x)
> {
>
> }
>
> bit x;
>
> if (x)
> {
>
> }
>
> what's the difference between these functions?
>
> bit x = true;
>
> bool x = true;
>
> What's the difference?

What's the difference between

bit x = true;

if(x){}

void *pv = cast(void*)(1);

if(pv){}

It's the same argument. Too logically unrelated types can be made to seem to have the same semantics in a limited set of circumstances. But this is a fool's paradise - not saying you're a fool, of course; I'd be direct if I was saying that ;) - since it is the ways in which the similarities fall down which catch us out. <self-promotion>I give a good long rant about this in Imperfect C++ - only a couple more months ...</self-promotion>

IMO, the "if(pv)" above should be illegal, and all conditional (sub-)expressions
must be explicitly boolean.

Thus

    int i;

    if(i) // error
    if(i != 0) // ok

    if(pv) // error
    if(null !== pv) // ok

This does not appeal to fans of terse code, but it does appeal to fans of maintenance and unambiguity.

Flame away, sigh ...

> bit has more functionality but it still supports all the functionality of bool.
>
> >I see no more commonality between them as between a pointer and, on a 32-bit architecture, int.
> >
> >We very much need a boolean type, otherwise the (IMO) majority of us who
> >want/need one will provide our own (as I have in std.recls,
std.windows.registry,
> >etc.) and we'll end up in exactly the same still-stinking mess that C/C++ is
in.
> >
> >
> Ok I've thought about it a bit more.  Your probably right, as long as bit doesn't loose all the functionality it has now I guess a bool type could be useful as sub-set of bit to prevent users from specifying numbers into functions.

I don't propose any change in bit whatsoever, save that true and false may no longer be implicitly used by it, or any other integral type. I want a boolean type that is:

- not implicitly convertible to any other type
- is the type of all conditional expressions
- is of variable size, according to context. It would default to a (time)
efficiently representation as the same size as the architecture, e.g. 32-bits, in
order to avoid the costs in the implicit "b = !b ? 0 : 1" evaluation. However, it
could be align'd to any alignment, right down to 1-bit, according to the user's
decision. The compiler will handle all issues regarding accessing by pointer.
(The one issue here is that accessing a bit by pointer is tricky, but could be
achieve by having a boolean ptr as a two-value entity. Not sure about this one as
yet, however ...)

These changes would make things ridiculously simple and umabiguous, without causing any of the storage or performance or correctness problems encountered in the boolean types of C/C++/Java.

"Bruno A. Costa" <bruno@codata.com.br> wrote in message news:c8vc34$k50$1@digitaldaemon.com...
> Derek Parnell wrote:
>
> > On Mon, 24 May 2004 17:03:11 +0000 (UTC), Arcane Jill wrote:
> >
> > [snip]
> >
> >> Personally, I would favor two distinct types: bit and bool, with bit being considered an arithmetic type (like a one bit wide unsigned integer), and bool able only to take values true and false. In this scenario, bits could be auto-promoted to int or uint (since those would be widening conversions) but bool could not (because logical types should not auto-convert to arithmetic types).
> >
> > 100% agree.
> >
> > 'bit' is a very small unsigned integer whose value is in the range 0
> > (zero) to 1 (one). And I presume 'sizeof(bit)' should return the number of
> > bytes the the implementation uses.
> >
> > 'bool' is NOT an integer. It can only have either of two values - TRUE or FALSE. But to make some people's lives a bit easier 'cast(bit)bool' ==> 0 for FALSE and 1 for TRUE.
> >
>
> This is good. I vote for a bool type.

Good.

> Or at least an implicit cast
> from boolean expressions to bit.

Bad, IMO. May I ask what uses you see for implicit conversion, and/or your objections to all such bool-integral conversions being explicit?

Cheers

Matthew

In article <c8vbnc$jfd$1@digitaldaemon.com>, J Anderson says...

>bool x;
>
>if (x)
>{
>
>}
>
>bit x;
>
>if (x)
>{
>
>}
>
>what's the difference between these functions?

The first would be legitimate.
The second would be a syntax error. The compiler would require if (x==1).



>bit x = true;
>
>bool x = true;
>
>What's the difference?

The first would be syntax error. The compiler would require bit x = 1; The second would be legitimate.



>Ok I've thought about it a bit more.  Your probably right, as long as bit doesn't loose all the functionality it has now I guess a bool type could be useful as sub-set of bit to prevent users from specifying numbers into functions.

Not a subset. In fact, not interchangable AT ALL without an explicit cast.

Arcane Jill

Arcane Jill wrote:

> Personally, I would favor two distinct types: bit and bool, with bit being
> considered an arithmetic type (like a one bit wide unsigned integer), and bool
> able only to take values true and false. In this scenario, bits could be
> auto-promoted to int or uint (since those would be widening conversions) but
> bool could not (because logical types should not auto-convert to arithmetic
> types).

+1. And expressions like (a == b) should return bool.

James McComb

J Anderson wrote:

> I'm against having two types.  Bit and bool overlap on just about all functionality.

I understand what you mean, but strictly speaking, if bit is arithmetic and bool is logical, they don't overlap at all.

Interface for bit: +, -, * , / etc.
Interface for bool: &&, || etc.

James McComb

Matthew wrote:
> I don't propose any change in bit whatsoever, save that true and false may no
> longer be implicitly used by it, or any other integral type. I want a boolean
> type that is:
> 
> - not implicitly convertible to any other type
> - is the type of all conditional expressions
> - is of variable size, according to context. It would default to a (time)
> efficiently representation as the same size as the architecture, e.g. 32-bits, in
> order to avoid the costs in the implicit "b = !b ? 0 : 1" evaluation. However, it
> could be align'd to any alignment, right down to 1-bit, according to the user's
> decision. The compiler will handle all issues regarding accessing by pointer.
> (The one issue here is that accessing a bit by pointer is tricky, but could be
> achieve by having a boolean ptr as a two-value entity. Not sure about this one as
> yet, however ...)

For what it's worth, I completely agree with Matthew. At least with his first two points.

I'm not sure if the size saving argument of point 3 really justifies the complexity of having a type with a variable size, though. My gut tells me that this kind of thing can cause lots of headaches and bug opportunities, both for the compiler writer and for the programmer who uses it.

I'd be happy if bool would be implemented(!) as an int, where !=0 is the same as true and 0 is false. So it basically means that the compiler has to translate bool==true to bool!=0 instead of bool==1 and boolA==boolB to a suitable construct that ensures correctness. Otherwise it could internally be treated as a typedef'ed int without arithmetic operations. Even Walter could use such a bool type ;) (he currently uses int instead of bit because int is faster).

The need to conserve memory for bools is so rare that I think this would be sufficient and it has the added benefit of being dead simple. If size should really become an issue (for example with huge bool arrays) the programmer still has the option to use bit instead. He won't have the advantages of a real bool type then, but at least he will be aware of the issues (since he explicitly chose bit) and can deal with them properly.

Note that I'm only talking about the internal implementation here. Bool should still be a completely independent type, of course, with no implicit conversions.

Hauke



> 
> These changes would make things ridiculously simple and umabiguous, without
> causing any of the storage or performance or correctness problems encountered in
> the boolean types of C/C++/Java.
> 
> 
> 
> 

Matthew wrote:

> 
> "Bruno A. Costa" <bruno@codata.com.br> wrote in message news:c8vc34$k50$1@digitaldaemon.com...
>> Derek Parnell wrote:
>>
>> > On Mon, 24 May 2004 17:03:11 +0000 (UTC), Arcane Jill wrote:
>> >
>> > [snip]
>> >
>> >> Personally, I would favor two distinct types: bit and bool, with bit being considered an arithmetic type (like a one bit wide unsigned integer), and bool able only to take values true and false. In this scenario, bits could be auto-promoted to int or uint (since those would be widening conversions) but bool could not (because logical types should not auto-convert to arithmetic types).
>> >
>> > 100% agree.
>> >
>> > 'bit' is a very small unsigned integer whose value is in the range 0
>> > (zero) to 1 (one). And I presume 'sizeof(bit)' should return the number
>> > of bytes the the implementation uses.
>> >
>> > 'bool' is NOT an integer. It can only have either of two values - TRUE or FALSE. But to make some people's lives a bit easier 'cast(bit)bool' ==> 0 for FALSE and 1 for TRUE.
>> >
>>
>> This is good. I vote for a bool type.
> 
> Good.
> 
>> Or at least an implicit cast
>> from boolean expressions to bit.
> 
> Bad, IMO. May I ask what uses you see for implicit conversion, and/or your objections to all such bool-integral conversions being explicit?
> 
> Cheers
> 
> Matthew

Well, as I said, my vote is for a bool type. The second option (but not the best option) is just to avoid casts like:

bit b;
b = cast(bit) (a==c);


So, I think we should stay witn the best.


Bruno.