I would suggest that bool NOT be an integer type.  All conditional tests should return bool and all conditional expressions should only accept bools, not integers.

That would mean no casts (implicit or explicit) from one to the other. The general idea is to prevent this classic bug:

int a,b;
if( a = b) ...

This returns an integer which is passed to the if.  Some compilers notice this and issue warnings, but that solution is not necessarily reliable and it increases compiler complexity.

Making bool's and int's different types also reduces the number of operators we need.  The &&, ||, and ~ operators could all be deprecated:

bool & bool        logical  AND
bool | bool          logical OR
!bool                  logical NOT

int & int              bitwise AND
int | int                bitwise OR
!int                     bitwise NOT

I suggest the & and | operators because they are shorter to type, and the ! operator over the ~ operator because it is better known.

Your points are well taken. One of my problems with a separate bool type is that a bool can have only two values, yet it is represented by a type that can contain many values. It just never seems to feel right. -Walter

Russ Lewis wrote in message <3B7D5282.5AF7C365@deming-os.org>...
>I would suggest that bool NOT be an integer type.  All conditional tests should return bool and all conditional expressions should only accept bools, not integers.
>
>That would mean no casts (implicit or explicit) from one to the other. The general idea is to prevent this classic bug:
>
>int a,b;
>if( a = b) ...
>
>This returns an integer which is passed to the if.  Some compilers notice this and issue warnings, but that solution is not necessarily reliable and it increases compiler complexity.
>
>Making bool's and int's different types also reduces the number of operators we need.  The &&, ||, and ~ operators could all be deprecated:
>
>bool & bool        logical  AND
>bool | bool          logical OR
>!bool                  logical NOT
>
>int & int              bitwise AND
>int | int                bitwise OR
>!int                     bitwise NOT
>
>I suggest the & and | operators because they are shorter to type, and the ! operator over the ~ operator because it is better known.
>

Walter wrote:

> Your points are well taken. One of my problems with a separate bool type is that a bool can have only two values, yet it is represented by a type that can contain many values. It just never seems to feel right. -Walter

Walter,

I would tend to agree with the original poster here.  If the programmer really cares about the non-zero value of a boolean value, then they're really looking for an integral value anyhow.  I don't know compiler theory all that well, but I would think that if the compiler were aware of the intention of using a boolean, that it could generate better assembly code as well.  I think there is a valuable semantic difference between the types, and the distinction can save much pain in using the language.  Add up the time that every programmer out there spends at least once, and usually numerous times, in there life finding the bug that the original poster mentioned, then multiply that by the potential millions who could use / derive value from this spec.

What is the cost of having a seperate boolean value, aside from a few characters in source files for the '== 0', and a relatively simple extra type in compilers?  Is there some other tradeoff that I'm missing here?

--

Ben Kuhn

Ben Kuhn wrote:

> Walter wrote:
>
> > Your points are well taken. One of my problems with a separate bool type is that a bool can have only two values, yet it is represented by a type that can contain many values. It just never seems to feel right. -Walter
>
> Walter,
>
> I would tend to agree with the original poster here.  If the programmer really cares about the non-zero value of a boolean value, then they're really looking for an integral value anyhow.  I don't know compiler theory all that well, but I would think that if the compiler were aware of the intention of using a boolean, that it could generate better assembly code as well.  I think there is a valuable semantic difference between the types, and the distinction can save much pain in using the language.  Add up the time that every programmer out there spends at least once, and usually numerous times, in there life finding the bug that the original poster mentioned, then multiply that by the potential millions who could use / derive value from this spec.
>
> What is the cost of having a seperate boolean value, aside from a few characters in source files for the '== 0', and a relatively simple extra type in compilers?  Is there some other tradeoff that I'm missing here?

What I've seen is a lot of people who use this:

rc = DoStuff()
if(rc)
  return rc;

Many of the people used to such tests would grumble to have to make it rc==0. However, most of these tests, happily, are *far* better handled with exceptions. :)

Ben Kuhn wrote in message <3B7D7887.A3EB66C8@improvsys.com>...
>What is the cost of having a seperate boolean value, aside from a few characters in source files for the '== 0', and a relatively simple extra
type
>in compilers?  Is there some other tradeoff that I'm missing here?


Sometimes there can be a penalty in the generated code, because !=0 values would have to be converted to boolean, as in:

    bool b = i ? 1 : 0;

There would also be confusion (I suspect) with the 'bit' type.

"Ben Kuhn" <benk@improvsys.com> wrote in message news:3B7D7887.A3EB66C8@improvsys.com...
>
> Walter,
>
> I would tend to agree with the original poster here.  If the programmer
really
> cares about the non-zero value of a boolean value, then they're really
looking
> for an integral value anyhow.  I don't know compiler theory all that well,
but
> I would think that if the compiler were aware of the intention of using a boolean, that it could generate better assembly code as well.  I think
there is
> a valuable semantic difference between the types, and the distinction can
save
> much pain in using the language.  Add up the time that every programmer
out
> there spends at least once, and usually numerous times, in there life
finding
> the bug that the original poster mentioned, then multiply that by the
potential
> millions who could use / derive value from this spec.
>
> What is the cost of having a seperate boolean value, aside from a few characters in source files for the '== 0', and a relatively simple extra
type
> in compilers?  Is there some other tradeoff that I'm missing here?
>
> --

Hi,
I think it has advantages and disadvantages;
maybe it's not such a big deal if bool is treated as an integer, as long as
the compiler generates proper warnings, like in the above mentioned (a=b)
case..
But I too tend to prefer the bool type to be treated in the more restrictive
way;
the ideal for me is bool can only be true/false 1/0 and no other value, rel
ops should return always boolean and if/while should expect boolean
expressions.
I think that the 0=false and other-than-zero = true approach of some
compilers can be misleading for the programmers (some at least :);
Example: suppose the programmer incidentally uses bitwise & instead of
logical && in the following case

bool MyFunction()
{
    a is 0x55  nonzero, -> true
    b is 0xAA nonzero, -> true

return a && b; // returns true
but...
return a & b;   // returns false

}

perfectly ok for the compiler if integer/bool can be freely mixed, however true and true = false  is not very intuitive.

Also, each approach has some influence on the generated code;
for example if the compiler cannot assume false always = 0 and true always =
1, there are some cases in which it is forced to use normalization tricks,
(like SBB etc. on the x86) which would (could) be unnecessary with a
restrictive bool type. (it can also happen the other way around tho'!)

--Luigi

"Walter" <walter@digitalmars.com> wrote in message news:9lk1k7$2b0f$1@digitaldaemon.com...
>
> Ben Kuhn wrote in message <3B7D7887.A3EB66C8@improvsys.com>...
> >What is the cost of having a seperate boolean value, aside from a few characters in source files for the '== 0', and a relatively simple extra
> type
> >in compilers?  Is there some other tradeoff that I'm missing here?
>
>
> Sometimes there can be a penalty in the generated code, because !=0 values would have to be converted to boolean, as in:
>
>     bool b = i ? 1 : 0;
>
> There would also be confusion (I suspect) with the 'bit' type.

I do generate that conversion in my compiler Walter. It is specified in the
ANSI C specs, and I think is a good thing. The code generated in x86
instructions (supposing the result already in a register)
    or    register
    setneq byte location

two instructions, not a big deal. Of course, sometimes there are other sequences that get generated, but at most a few instructions. Not a big deal, and you are sure that all booleans are either zero or one... This is a conceptual simplification that is worth the few instructions. At 1GHZ now, this doesn't matter much any more.

jacob navia wrote in message <9lk5jl$2eb9$1@digitaldaemon.com>...
>two instructions, not a big deal. Of course, sometimes there are other sequences that get generated, but at most a few instructions. Not a big deal, and you are sure that all booleans are either zero or one... This is
a
>conceptual simplification that is worth the few instructions. At 1GHZ now, this doesn't matter much any more.


I'll have to disagree that a few extra instructions are painless at 1GHz. For example, when I turn my machine on the morning, I go off and get some coffee, chat with friends, run errands, read the paper, and by the time I get back it's almost at the logon prompt <g>.

"Russ Lewis" <russ@deming-os.org> wrote in message news:3B7D5282.5AF7C365@deming-os.org...
> I would suggest that bool NOT be an integer type.  All conditional tests should return bool and all conditional expressions should only accept bools, not integers.


Hear! Hear!

Cheers,
John Carney.

John Carney wrote:

> "Russ Lewis" <russ@deming-os.org> wrote in message news:3B7D5282.5AF7C365@deming-os.org...
> > I would suggest that bool NOT be an integer type.  All conditional tests should return bool and all conditional expressions should only accept bools, not integers.
>
> Hear! Hear!
>
> Cheers,
> John Carney.

LOL!

Of all my ideas for changes to D, I thought that this one would be by far the most controversial.  Shows what I know...