In article <9336115.21034@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

>>> bool b = strcmp(s1, s2);

>Perhaps you misunderstood.  I was intending to use the bool variable
>`b' in the above example only in boolean contexts.

Ah...then I think we agree.

Suppose I say

 int x = strcmp(s1, s2);

Then perhaps I care about three cases: x<0, x==0, x>0.
On the other hand, perhaps I care only about two cases,
namely x==0 and x!=0.  In the latter instance, I can
make x into a bool, but in the former I cannot.

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
> I wrote:
> > ...
> >(which BTW introduces a loop in the implicit conversions
> >directed graph).

> The graph was already cyclic.
> Consider short -> long -> short.

Sorry; bad phrasing on my part... I should have said introduces _another_
loop.

> >I am still waiting for _any_ reason why the current rules are superior
> >to these I suggested. So far we had:
> >
> >- Breaking of code; Can anyone post an example of useful/common code that
> >  breaks?

> I consider

>  bool b = strcmp(s1, s2);

> reasonable usage, in C or C++ without a bool type.
> I imagine that it is probably relatively common.
> I think this example breaks under your suggested rules.

I assume that the addition of bool to the compiler will be accompanied by
modifying the relevant library functions to use it. This takes care
of bool functions as isupper(c).

As for strcmp... You got me there. However, in my experience, the much more
common use is:

 bool is_eq = !strcmp(s1, s2);
 bool is_gt = strcmp(s1, s2) > 0;

Which does not break under my rules. Further, strcmp (and memcmp) are rather
special in this respect. Given that all you get is a warning, and that the fix
is two characters long, I would argue that the additional safety is worth it.

It boils down to the question of attitude towards implicit lossy conversions.
Given that they are considered reasonable, there is nothing wrong with the
committee's decision; I therefore guess that this is the committee's view.

I personally would really like to get a warning whenever an implicit lossy
conversion occurs. Since the committee disagrees, I'll just look around for
compilers which supports it as an optional warning. Sadly I lack the time
to add a -Wimplicit_lossy_conversion to g++...

      Oren.

--

Could someone please repost (or better yet, email to
haydens@ll.mit.edu) the new boolean type proposal. I missed it by a
day or so. Unfortunately, I find that activites such as eating and
sleeping make it very difficult to keep up with the traffic in this
newsgroup.

 Thanks,

 Hayden

--
Hayden Schultz
haydens@ll.mit.edu
MIT Lincoln Lab
244 Wood St.
Lexington, MA, 02173
(617) 981-3685

Sorry, it's comp.lang.c++, not comp.std.c++ that's really verbose.
But, I'd still appreaciate a copy of the proposal.

 Thanks again,

 Hayden
--
Hayden Schultz
haydens@ll.mit.edu
MIT Lincoln Lab
244 Wood St.
Lexington, MA, 02173
(617) 981-3685

In article <1993Dec17.120147.8306@wisipc.weizmann.ac.il> oren@pashosh.weizmann.ac.il (Ben-Kiki Oren) writes:

> (Pinch self. Hard. He has really said that.)
>
> I don't know how to say it politely, but we already have `special rules that
> apply only for conversions to bool and no other type'. There is a special rule
> that says that there exist an implicit conversion from any integer, floating,
> or pointer type to it. Shocking, isn't it?

There is a difference between (a) taking a rule that already exists and
changing slightly the situations in which applies and (b) inventing a
completely new rule.

> I suppose I can't argue with a "don't case" attitude, except to say that some
> programmers _do_ care about type safety, and that type safety was once upon a
> time a major driving force in the design of C++. Has that changed?

No it hasn't.

And as I and others have said several times, one advantage of making bool
a separate type is that compiler vendors can now issue warnings in situations
they could not successfully distinguish before.

Much as you might like things to be otherwise, it is not possible to change
instantly from an unsafe situation to a completely safe one if that change
must be voted on by a committee.

> Let us separate debating from moaning.

Yes, let's.
--
    --Andrew Koenig
      ark@research.att.com

oren@pashosh.weizmann.ac.il (Ben-Kiki Oren) writes:

>Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
>>
>> I consider
>
>>  bool b = strcmp(s1, s2);
>
>> reasonable usage, in C or C++ without a bool type.
>> I imagine that it is probably relatively common.
>> I think this example breaks under your suggested rules.
>
>I assume that the addition of bool to the compiler will be accompanied by
>modifying the relevant library functions to use it. This takes care
>of bool functions as isupper(c).

This is a very bad assumption.  It certainly won't be true for
third-party libraries.  The standard must allow the transition
to be gradual, otherwise it just won't happen.

--
Fergus Henderson        |   "People who brook no compromise in programming
                        |   languages should program in lambda calculus or
fjh@munta.cs.mu.OZ.AU   |   machine language, depending." --Andrew Koenig.

rfg@netcom.com (Ronald F. Guilmette) writes:
>
>In short, I believe it would make sense to DISALLOW all arithmetic operations
>on type `bool'.  If someone wants to set a type bool variable to true, let
>them write:
>
>  my_bool_var = true;
>
>I find that to be far more clear and obvious that the (cryptic) alternative
>of:
>
>  my_bool_var++;
>
>Note also that if the intent is that type `bool' variables should hold
>*only* the quantities true or false (presumably represented by 1 and 0
>respectively) then an actual hardware-level "increment" is most definitely
>NOT the proper way to set a `bool' to the value true.  In particular,
>an actual hardware-level increment of a `bool' variable which already
>has the value true (1) would result in a new value (2) which is not even
>a valid `bool' value.

I strongly agree with this.  I have seen old C code that used b++ to
mean b=true.  In some loop contexts I would describe this usage as a
bug, since b can be incremented so many times it ends up back at 0 (and
neither C nor C++ check for integer overflow).  I don't know what the
advantage of b++ is supposed to be:  doesn't it use more cpu cycles
than b=1?  Why can't people just say what they mean??

--
James Cribb (jamesc@dev.state.com.au)
Group Treasury, State Bank of NSW Limited
(Opinions not necessarily those of my employer.)

In article <9335400.25904@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

>I consider
>
> bool b = strcmp(s1, s2);
>
>reasonable usage, in C or C++ without a bool type.

If you think it is reasonable to use `bool' to name something that
has more than two relevant states, then you should fix the compilation
error that results from the new keyword by picking a new name for
your type.

ark@tempel.research.att.com (Andrew Koenig <9577-82971> 059113A) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>>I consider
>>
>> bool b = strcmp(s1, s2);
>>
>>reasonable usage, in C or C++ without a bool type.
>
>If you think it is reasonable to use `bool' to name something that
>has more than two relevant states, then you should fix the compilation
>error that results from the new keyword by picking a new name for
>your type.

Perhaps you misunderstood.  I was intending to use the bool variable
`b' in the above example only in boolean contexts.  With the proposal
which has been accepted by the committee, the code would continue
to work fine.  I was using the example to point out that it's not
reasonable to outlaw implicit int->bool conversions, as suggested by
Ben-Kiki Oren, because it would break reasonable existing code.

Note that I consider the above code bad style in C++ now that the
language has a boolean type.  I would expect good compilers to offer an
option to warn about such implicit conversions.  But it should be only
a warning, and an optional one at that, not an error.

Lest anyone be unsure of my position, let me make it clear that I
believe the committee has done an excellent job with the new bool
type.  I think the rules they adopted combine maximum benefit with
minimum damage.  Thanks!

--
Fergus Henderson        |   "People who brook no compromise in programming
                        |   languages should program in lambda calculus or
fjh@munta.cs.mu.OZ.AU   |   machine language, depending." --Andrew Koenig.

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
> I consider
>
>  bool b = strcmp(s1, s2);
>
> reasonable usage, in C or C++ without a bool type.

[discussion omitted]

> Perhaps you misunderstood.  I was intending to use the bool variable
> `b' in the above example only in boolean contexts.  With the proposal
> which has been accepted by the committee, the code would continue
> to work fine.  I was using the example to point out that it's not
> reasonable to outlaw implicit int->bool conversions, as suggested by
> Ben-Kiki Oren, because it would break reasonable existing code.

> Note that I consider the above code bad style in C++ now that the
> language has a boolean type.  I would expect good compilers to offer an
> option to warn about such implicit conversions.  But it should be only
> a warning, and an optional one at that, not an error.

I agree you can't outlaw the conversion because too much code will be broken.
Making it deprecated would have been reasonable, just like was done for '++'.
However it really is a separate issue - the legality of implicit lossy
conversions - so I agree that bool is probably not the right place to start
dealing with it.

> Lest anyone be unsure of my position, let me make it clear that I
> believe the committee has done an excellent job with the new bool
> type.  I think the rules they adopted combine maximum benefit with
> minimum damage.  Thanks!

And thanks for Dag Bruck and Andrew Koenig for pushing it through.

      Oren.

--

warwick@cs.uq.oz.au (Warwick Allison) writes:

>chase@Think.COM (David Chase) writes:

>>|> If &&= existed, that would be the sensible operator to use for bool
>>|> operatnds.

>>I find this reasoning mystifying.  Since "&=" is an integer operation, ...

>The semantics of "lhs &&= rhs" would, I presume be:

>if (!lhs) lhs=rhs;

Cough, cough. I'd think that this would rather be the behaviour for ||=
For &&=, delete the !
--
 David Kastrup        dak@pool.informatik.rwth-aachen.de
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen

In <comp.std.c++> oren@pashosh.weizmann.ac.il (Ben-Kiki Oren) writes:

[Description deleted.]

>And how does my suggestion fail to satisfy the above? Can you please give an
>example?

How does your proposal differ from the one that was accepted?

>Now as for type safety. The current bool rules allow monstrosities such as:
>
> int x = 19, y = 23;
> bool b = x * 7 + y / 18 - getchar();
> b = x * b + y & b;
> b = b - b - b / b + b * b;

Yes, that is the price you pay for implict conversion from int to
bool.  Note that the expressions are evaluated as ints, and the int
value is then converted to a bool.

     -- Dag

In article <16759@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes:

> The semantics of "lhs &&= rhs" would, I presume be:

> if (!lhs) lhs=rhs;

Well,
 if (lhs) lhs = rhs;

anyway...
--
    --Andrew Koenig
      ark@research.att.com

In article <1993Dec13.111313.24678@wisipc.weizmann.ac.il> oren@pashosh.weizmann.ac.il (Ben-Kiki Oren) writes:

> And it does, under my suggestion. Because 'b &= 2' becomes:

>  b = (bool)((int)b & 2)

> and under rule (2) above the conversion int -> bool is flagged as an error.

... but only at the cost of having special rules that apply only to
conversion to bool and to no other type.  I suppose this might have been
possible, but it's far from clear the committee would have accepted it.
It's an awful lot of extra complexity, compared to saying that the rules
for bool are the same as for all the other integral types.

> Now as for type safety. The current bool rules allow monstrosities such as:

>  int x = 19, y = 23;
>  bool b = x * 7 + y / 18 - getchar();
>  b = x * b + y & b;
>  b = b - b - b / b + b * b;

> Now, is 'b' clearly used as a Boolean in the above statements?

I don't care.  It is useful to keep the rules simple and allow existing
reasonable usages to continue.  If the price for that is making it possible
for people to write monstrosities, that's OK with me.  They'll figure
out how to do it in any case.

> It seems to me you pay a higher price, get less type safety, allow + - * / on
> bools, which have no meaning, but disallow & | ~ which do have a clear
> meaning... IMVHO once it is implemented this will become yet another source
> for recurrent threads in comp.lang.c++, like the for scoping rule, the
> definition of NULL, and a few others I could mention (weep).

But of course.

I can guarantee that *no matter what* is implemented, including nothing,
there will be a significant number of people on comp.lang.c++ who will
weep and moan about it.  That can't be helped.
--
    --Andrew Koenig
      ark@research.att.com

In article <2eaotcINNjdb@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
 >In article <2e7p0u$gvr@ornews.intel.com> ajw@ornews.intel.com (Alan Waldock) writes:
 >>I may be out of my depth here, but I'm not sure I understand the bit
 >>about existing code getting broken if you did what RFG suggests.
 >>Any integer in an existing program would surely still be allowed to
 >>have ++ applied, whether it was a "conceptual Boolean" or not.  If
 >>the programmer changes it to a type 'bool', it's not existing code
 >>any more -- and I'm awfully sorry, but the "programmer compatibility"
 >>argument sounds VERY thin against the type safety advantages that
 >>a restricted set of appropriate operations might bring.
 >
 >I disagree.
 >
 >If changing a variable to type bool is going to force the programmer to
 >examine and update all the uses of the variable, he's more than likely not
 >going to bother updating the declaration.

 Well, that's thin too.  All that I've read so far suggests that use of the
 new type is merely going to be legal, not compulsory.

 Look, I do understand the motivation of wanting to be gentle and tie
 shoelaces and wipe noses and all that -- and I also know that nothing
 I say is going to sway the committee (nor, probably, should it); it's
 just that I _enjoy_ using this language a little more each day, and I
 get a little more productive with it each day, and mostly the reason is
 because it does what it's supposed to do. And here comes a new type, the
 only point of which is to make it a little harder to shoot oneself in the
 foot, and for reasons that nobody will give a tailor's cuss about in six
 months it comes fully loaded with dum-dums.

 I just think it's a shame, that's all. Probably shouldn't have had that
 third pickled onion.

-- Alan Waldock, from but not on behalf of Intel Corporation
   ajw@guardian.intel.com

ark@alice.att.com (Andrew Koenig) writes:

>In article <16759@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes:

>> The semantics of "lhs &&= rhs" would, I presume be:

>> if (!lhs) lhs=rhs;

>Well,
> if (lhs) lhs = rhs;

>anyway...

Perhaps the fact that this simple notion was miscoded is a reason to
consider addition of &&= to the language :-)
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

In article <2e9939$hsg@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
|I think you misunderstand something fundamental here.  There is only
|one "arithmetic" operator defined for bool: operator ++.

Further, what has been left unsaid so far, is that if one is 'given'
the bidi conversions, then it is necessary that other binary operators
*not* be defined for bools.  If they were, then much existing
code would be broken:

 int a, c;
 int b();

 ((a || b()) & c)

becomes ambiguous, since it reduces as:

 ((int || int) & int)

becomes:

 (bool & int)

which is ambiguous.  Does the compiler resolve it to:

 (int(bool) & int)

or

 (bool & bool(int))

????

with the current proposal of NOT defining these other bool
operators, then:

 f((a || b()) & c)

resolves to calling:

 f(int);

which is the same f as would have been called before.

This in turn demonstrates the strengths and weaknesses of the proposed
scheme.  Namely, if someone makes a simple mistake in their type
calculus, such as using '&' instead of '&&':

 bool a, b;
....
 f(a & b);

vs

 f(a && b);

then the 'wrong' overloading of f will *still* be called.

So again, I'm far from convinced the cure is better than the disease.
Once you insist on the bidi rule, then 'bool' don't buy you much, IMHO.
But if you don't allow the bidi rule, then much if most existing code
is broken.

Again, wanting a solution is not the same as having one.

In article <2eioh0$7u6@ornews.intel.com> ajw@ornews.intel.com (Alan Waldock) writes:

>  And here comes a new type, the
>  only point of which is to make it a little harder to shoot oneself in the
>  foot, and for reasons that nobody will give a tailor's cuss about in six
>  months it comes fully loaded with dum-dums.

No, that's not the point.  The Boolean type is there for two reasons:

 1. Overloading.  Unless bool is a built-in type, there is no way
 to overload based on it, because the built-in relational operators
 can't be made to return anything else than what they usually do.

 In other words, without a built-in bool type, there is no way for

  cout << (3 < 4);

 to print anything different than

  cout << 1;

 regardless of how much the programmer might want it to do so.

 2. Combining libraries.  Right now lots of libraries define
 their own Boolean types, all incompatibly.  That cries out for
 a single, standard way of doing it.

Safety would be nice too, but not where it breaks code.  After all, if you
want to sacrifice compatibility for safety, you can always rewrite your
program in a safer language.  There are plenty of them out there.
--
    --Andrew Koenig
      ark@research.att.com

oren@pashosh.weizmann.ac.il (Ben-Kiki Oren) writes:

>I suggested:
[...]
>Two special rules apply to bools:
>
>2) As a special case, the conversion T -> bool (T == (T)0) is allowed
>   _only_ for types for which (T)0 makes sense (char short int long float
>   double T*) and _only_ in an if, for or while condition, or for operands of
>   && || and !. This allows for the current uses, so we don't break code.
>
>   Anywhere else this conversion is illegal, and produces an error (I'll
>   settle for a warning if too much existing code is involved). This breaks
>   the code we want to break.

With the proposal that the committee accepted, you have to settle for
a warning.

>3) As a special case, applying arithmetic operators + - * / to bools is
>   illegal (you can do it if you are mixing a bool with another arithmetic
>   type). += -= *= /= and -- should definitely be banned for bools. ++ might
>   be allowed, if code depends on it, but it should at least be depreciated.
>   This breaks the rest of the code we want to break.

Again, you'll have to settle for a warning.

I think that the committee made the right decision in both these
cases.  IMHO it's best if existing code isn't broken, even if it
is a bit loose with int/bool conversions, because a warning is
quite sufficient.  And we don't want to burden the language with
lots of special case rules.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

Dag Bruck (dag@control.lth.se) wrote:
> How does your proposal differ from the one that was accepted?

Mainly in that it does not contain the implicit int -> bool conversion. This
conversion, as pointed out by other posts, is the root of the problem. If you
disallow it, the rest follows naturally - making bool an (almost) normal
integer type, allowing _safe_ & | ^ ~ (and their op= versions) on bools, and
catching monstrosities such as those described below.

> I wrote:
> >Now as for type safety. The current bool rules allow monstrosities such as:
> >
> > int x = 19, y = 23;
> > bool b = x * 7 + y / 18 - getchar();
> > b = x * b + y & b;
> > b = b - b - b / b + b * b;

> Yes, that is the price you pay for implict conversion from int to
> bool.  Note that the expressions are evaluated as ints, and the int
> value is then converted to a bool.

And _why_ do we need to put up with the int -> bool conversion? It was claimed
that disallowing it would break code. My suggestion was to allow it only in
specific places - if, for, and while conditions and operands for && || and !.

It is also possible to start by making the conversion a depreciated feature,
if preserving the legality of current warped code is an issue. Just like what
was done for ++.

I claim is that this will preserve the code we don't want to break and break
the code we don't want to preserve. I am still waiting for someone to prove me
wrong, by posting code that would break under my suggested rules and is
useful, or at least common practice.

Until such code is posted, I'll stick by my opinion that the current rules
are, ehm, less then optimal, and should be fixed before its too late.

      Oren.

--

Has any compiler writer tried out the new "bool" proposal on real code? If
so, what kind of damage was caused (if any)?
Doug Gilbert

In <comp.std.c++> oren@pashosh.weizmann.ac.il (Ben-Kiki Oren) writes:
>
>And _why_ do we need to put up with the int -> bool conversion? It was claimed
>that disallowing it would break code. My suggestion was to allow it only in
>specific places - if, for, and while conditions and operands for && || and !.
                   11111111111111111111111111111     222222222222222222222222

>It is also possible to start by making the conversion a depreciated feature,
>if preserving the legality of current warped code is an issue. Just like what
>was done for ++.

Well, the original proposal as presented to the committee suggested
the stuff I have marked with "1" and proposed the stuff I marked with
"2" as a deprecated feature.  That seems to be very close to your view.

However, the committee changed the proposal so "2" is a non-deprecated
feature.  The authors were willing to accept that change, in order to
get the whole proposal through.  I can't everything every time.

>Until such code is posted, I'll stick by my opinion that the current rules
>are, ehm, less then optimal, and should be fixed before its too late.

I agree with the first part, but I don't think it's worth the fuzz to
fix them.
     -- Dag

In <comp.std.c++> dpg@extro.ucc.su.OZ.AU (D P Gilbert) writes:
>
>Has any compiler writer tried out the new "bool" proposal on real code? If
>so, what kind of damage was caused (if any)?
>Doug Gilbert

Sean Corfield, a member of the committee, did indeed change his
compiler.  The new boolean type worked as advertised:

 - old definitions of "bool" had to be removed

 - the code compiled and worked as before.

We'll, Sean actually did find a bug in his code, but I'll leave to
him to write about it if he wants to.

    -- Dag

Ben-Kiki Oren (oren@pashosh.weizmann.ac.il) wrote:
: Why no &= for bool?

: Andrew Koenig (ark@alice.att.com) wrote:
: > No, the reasoning was ``well, if we implemented it according to the
: > bool <--> int rules, it would do the wrong thing.''
:        ^^
: This direction is the source of the problem.

: > [ Stuff deleted ]

: > Now let's look at the Boolean case:

: >  bool b = true;

: >  b &= 2;

: > If this were allowed at all, the only plausible interpretation
: > would be to treat it the same way as

: >  b = b & 2;

: > Now, b & 2 is computed by converting b to int, yielding (1 & 2) or 0.
: > This would be true even if it were written, say, this way:

: >  b &= isupper(c);

: > where the particular implementation of isupper happens to return 2.
: > (If you think isupper should return a bool, substitute some other
: > function that returns an int for historical reasons).

: There are two points hiding here. The first is that & | ^ ~ are not defined
: for bool (at least, they were not listed in the allowed operators list in the
: post describing bool). Why not? && and || exist for the short-circuit
: semantics. Why deny bool variables the non-short-circuit operators? Just as +
: - * / exist for ints and floats (with appropriate promotions), why shouldn't &
: | ^ ~ exist for bools and ints (again, with appropriate promotions)? This
: would make the following legal:

:  b &= b1;

: And would eliminate the cast-to-int-and-back in the perfectly reasonable:

:  b = b1 & b2;  // Note non-short-circuit expression

: The second point is that all the above assignments, under current rules, cast
: an int value to a bool. If the & | ^ ~ operators were allowed for bools, this
: cast would be gone - except for the 'isupper' example above. Now, a cast from
: an int to a bool is rather information-lossy. IMHO it should create a warning
: every time it occurs, with the exception of the condition in an if, for or a
: while statement and operands of && || and !. This will preserve the legality
: of most current code that relies on implicit T* -> bool and int -> bool
: conversions. As a first step, the conversion (outside the above contexts)
: should be declared as a depreciated feature, so no code would actually break.

: Providing an explicit cast is trivial. You just need to type two more
: characters:

:  b &= !!isupper(c); // If isupper returns an int for some reason

: Which is really not too high a price for type safety, is it? Type safety used
: to be one of C++ advantages over C. Allowing unrestricted int/T* -> bool
: conversions would weaken this. Any chance it will be limited?

: > So the real problem is that &= just isn't the right operation.

: No, it is exactly the right operator, if only you don't need a short-circuit
: operator.

: > Well, what is?  I can readily imagine an operation

: >  a &&= b

: > being defined as equivalent to

: >  (a = (a? b: false))

: > except that `a' is evaluated only once, and similarly for ||=.

: > However, that proposal is logically separable from the proposal
: > for the Boolean type and neither Dag nor I felt it was useful
: > enough to propose it.

: Agreed. &&= is to &= what && is to &. Its usefulness is a completely separate
: issue.

: --
: Life is tough and the hard ships are many.


Yes

Andrew Koenig (ark@alice.att.com) wrote:
> I wrote:
> > ... Because 'b &= 2' becomes:

> >  b = (bool)((int)b & 2)

> > and under rule (2) above the conversion int -> bool is flagged as an error.

> ... but only at the cost of having special rules that apply only to
> conversion to bool and to no other type.  I suppose this might have been
> possible, but it's far from clear the committee would have accepted it.
> It's an awful lot of extra complexity, compared to saying that the rules
> for bool are the same as for all the other integral types.

(Pinch self. Hard. He has really said that.)

I don't know how to say it politely, but we already have `special rules that
apply only for conversions to bool and no other type'. There is a special rule
that says that there exist an implicit conversion from any integer, floating,
or pointer type to it. Shocking, isn't it?

``This is a new usage of the word "same" I was not aware of before''.

As for `an awful lot of extra complexity'. It seems to me as though
unconditional conversion of whatever expression to a bool in a small set of
places is not `awfully more complex' then allowing unrestricted implicit
conversion anywhere (which BTW introduces a loop in the implicit conversions
directed graph).

> > Now as for type safety. The current bool rules allow monstrosities such as:

> >  int x = 19, y = 23;
> >  bool b = x * 7 + y / 18 - getchar();
> >  b = x * b + y & b;
> >  b = b - b - b / b + b * b;

> > Now, is 'b' clearly used as a Boolean in the above statements?

> I don't care.  It is useful to keep the rules simple and allow existing
> reasonable usages to continue.  If the price for that is making it possible
> for people to write monstrosities, that's OK with me.  They'll figure
> out how to do it in any case.

I suppose I can't argue with a "don't case" attitude, except to say that some
programmers _do_ care about type safety, and that type safety was once upon a
time a major driving force in the design of C++. Has that changed?

As for allowing reasonable usages... You consider the above to be reasonable?

> > It seems to me you pay a higher price, get less type safety, allow + - * / on
> > bools, which have no meaning, but disallow & | ~ which do have a clear
> > meaning... IMVHO once it is implemented this will become yet another source
> > for recurrent threads in comp.lang.c++, like the for scoping rule, the
> > definition of NULL, and a few others I could mention (weep).

> But of course.

> I can guarantee that *no matter what* is implemented, including nothing,
> there will be a significant number of people on comp.lang.c++ who will
> weep and moan about it.  That can't be helped.

Let us separate debating from moaning. The net does debate about many C++
features. But I haven't seen any posts _moaning_ the postfix vs. prefix -- and
++ operators syntax; or the fact that MI was introduced; or the fact that
variables declared inside an if statement have the if statement's scope, or
many other of many other reasonable things. We have enough unreasonable things
to moan about that there is hardly a need to moan over the reasonable ones.
Give the net _some_ credit.

I am still waiting for _any_ reason why the current rules are superior
to these I suggested. So far we had:

- Breaking of code; Can anyone post an example of useful/common code that
  breaks?

- Special rules; As if the current rules are not 'special'. Both the
  alternatives involve special rules. Can anyone demonstrate that my
  suggested rules are 'more special'?

- Additional complexity. I don't see that my rules are more complex to
  implement; IMHO adding bool as a normal integer type at the bottom of the
  implicit conversions path should be easy, and adding an 'invisible implicit
  conversion' in specific locations (conditions and operands of boolean
  operators) is not too difficult either. The current suggestion requires
  compiler changes as well; Can anyone involved with compiler writing/hacking
  comment on the relative complexity?

      Oren.

--

Dag Bruck (dag@control.lth.se) wrote:
: In <comp.std.c++> oren@pashosh.weizmann.ac.il (Ben-Kiki Oren) writes:
: >
: >And _why_ do we need to put up with the int -> bool conversion? It was claimed
: >that disallowing it would break code. My suggestion was to allow it only in
: >specific places - if, for, and while conditions and operands for && || and !.
:                    11111111111111111111111111111     222222222222222222222222

: >It is also possible to start by making the conversion a depreciated feature,
: >if preserving the legality of current warped code is an issue. Just like what
: >was done for ++.

: Well, the original proposal as presented to the committee suggested
: the stuff I have marked with "1" and proposed the stuff I marked with
: "2" as a deprecated feature.  That seems to be very close to your view.

Great !!!!!!! That's what we want !!!!

: However, the committee changed the proposal so "2" is a non-deprecated

Oh God !!!! :(((( You guys let 'em do that !!!!!!!! :((((((

: feature.  The authors were willing to accept that change, in order to
: get the whole proposal through.  I can't everything every time.

: >Until such code is posted, I'll stick by my opinion that the current rules
: >are, ehm, less then optimal, and should be fixed before its too late.

: I agree with the first part, but I don't think it's worth the fuzz to
: fix them.
:      -- Dag

oren@pashosh.weizmann.ac.il (Ben-Kiki Oren) writes:

>As for `an awful lot of extra complexity'. It seems to me as though
>unconditional conversion of whatever expression to a bool in a small set of
>places is not `awfully more complex' then allowing unrestricted implicit
>conversion anywhere

I wouldn't say "awfully more complex", but I would say "somewhat more
complex".  And although the additional complexity isn't great,
I don't think it buys us much.

>(which BTW introduces a loop in the implicit conversions
>directed graph).

The graph was already cyclic.
Consider short -> long -> short.

>I am still waiting for _any_ reason why the current rules are superior
>to these I suggested. So far we had:
>
>- Breaking of code; Can anyone post an example of useful/common code that
>  breaks?

I consider

 bool b = strcmp(s1, s2);

reasonable usage, in C or C++ without a bool type.
I imagine that it is probably relatively common.
I think this example breaks under your suggested rules.

>- Additional complexity. I don't see that my rules are more complex to
>  implement; IMHO adding bool as a normal integer type at the bottom of the
>  implicit conversions path should be easy, and adding an 'invisible implicit
>  conversion' in specific locations (conditions and operands of boolean
>  operators) is not too difficult either. The current suggestion requires
>  compiler changes as well; Can anyone involved with compiler writing/hacking
>  comment on the relative complexity?

I was more worried about overall language complexity than difficulty of
implementation.  My guess is that your proposal would probably be slightly
more difficult to implement, but I don't think the difference would be
very significant.

--
Fergus Henderson        |   "People who brook no compromise in programming
                        |   languages should program in lambda calculus or
fjh@munta.cs.mu.OZ.AU   |   machine language, depending." --Andrew Koenig.

ark@alice.att.com (Andrew Koenig) writes:
[elided discussion on why { int n = 4; n *= 1.3; } should leave n=5.]

>Now let's look at the Boolean case:
> bool b = true;
> b &= 2;

>If this were allowed at all, the only plausible interpretation
>would be to treat it the same way as
> b = b & 2;

>Now, b & 2 is computed by converting b to int, yielding (1 & 2) or 0.
>This would be true even if it were written, say, this way:
> b &= isupper(c);

>where the particular implementation of isupper happens to return 2.
>(If you think isupper should return a bool, substitute some other
>function that returns an int for historical reasons).
>So the real problem is that &= just isn't the right operation.

I disagree.  C and C++ both have define more than one multiply operator.
They overload the '*' to mean multiply for integers and for floats at least.
They do completely different things (although conceptually it's the same).

It seems quite natural to me to have the &, | and ^ operators overloaded
for bool.  Just like it is wrong to convert float to int and use the int
version of *, it could be wrong to convert bool to int and use the int
versions of &, | and ^.

It makes sense to define the effect of these operators on type bool
according to what most people would expect the effect to be.  I like
the principle of least surprise.

>Well, what is?  I can readily imagine an operation
> a &&= b
>being defined as equivalent to
> (a = (a? b: false))
>except that `a' is evaluated only once, and similarly for ||=.

>However, that proposal is logically separable from the proposal
>for the Boolean type and neither Dag nor I felt it was useful
>enough to propose it.

Seems to me that to propose a new type necessitates the discussion of
how the type behaves with regard to operators that may used with them.
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

In article <27285@alice.att.com> ark@alice.UUCP () writes:
>
>...  I can readily imagine an operation
>
> a &&= b
>
>being defined as equivalent to
>
> (a = (a? b: false))
>
>except that `a' is evaluated only once, and similarly for ||=.
>
>However, that proposal is logically separable from the proposal
>for the Boolean type and neither Dag nor I felt it was useful
>enough to propose it.

So you've given us a new type, but an incomplete set of operations for
that type.  I find that unfortunate.

I would also like to mention that it seems altogether wrong to permit
*any* "arithmetic" operations (e.g. increment) on this new `bool' type.
This type is *not* (after all) supposed to represent arithmetic quantities,
right?

In short, I believe it would make sense to DISALLOW all arithmetic operations
on type `bool'.  If someone wants to set a type bool variable to true, let
them write:

  my_bool_var = true;

I find that to be far more clear and obvious that the (cryptic) alternative
of:

  my_bool_var++;

Note also that if the intent is that type `bool' variables should hold
*only* the quantities true or false (presumably represented by 1 and 0
respectively) then an actual hardware-level "increment" is most definitely
NOT the proper way to set a `bool' to the value true.  In particular,
an actual hardware-level increment of a `bool' variable which already
has the value true (1) would result in a new value (2) which is not even
a valid `bool' value.

I see no point in introducing a new boolean type (presumably as a better
alternative than the old reliable ints) if programmers will still be
permitted to (mistakenly) blur the distinction between arithmetic operations
and strictly boolean operations.

Don't get me wrong.  Having a `bool' type is probably a Good Thing, but
one of the major arguments in favor of such a type is that it can give you
better "type safety".  Unfortunately, that advantage will be lost if
*arithmetic* operations are still permitted upon values of this new type.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>In short, I believe it would make sense to DISALLOW all arithmetic operations
>on type `bool'.  If someone wants to set a type bool variable to true, let
>them write:
>
>  my_bool_var = true;

I agree completely, but I find the implicit conversion of int and
pointer to bool a bigger problem.  Unfortunately, there seems to be a
lot of C++ code that uses ++ on something that is conceptually a
Boolean type.  The committee decided to abandon some technical
advantages in order to preserve existing code (and coding practices,
let's not forget programmer compatibility).

>Note also that if the intent is that type `bool' variables should hold
>*only* the quantities true or false (presumably represented by 1 and 0
>respectively) then an actual hardware-level "increment" is most definitely
>NOT the proper way to set a `bool' to the value true.  In particular,
>an actual hardware-level increment of a `bool' variable which already
>has the value true (1) would result in a new value (2) which is not even
>a valid `bool' value.

I don't think the proposal allows that "b++" is implemented as a
hardware-level increment.  The proposal says that "b++" sets b to
true, but does not impose any restriction on the number of times you
may do it.

The proposal says quite clearly that a bool, when promoted to int,
yields the values 0 or 1; how that is represented is not specified,
and need not be specified in my view.


     -- Dag

Andrew Koenig (ark@alice.att.com) wrote:

: Very briefly,

:  converting numeric or pointer type to bool takes 0 to false
:  and anything else to true

:  bool promotes to int, taking false to 0 and true to 1

By "promotes" I take it that you mean that they will automatically
convert where needed.  If this is so, then does this not break one of
the principal reasons for having a separate "bool" type -  namely
that of type safety?  If all of my ints will freely convert to bools,
and all of my bools will freely convert to ints how is there any
real difference between having or not having a separate bool type?
I can still go:

if (42)
    do_something;

I should have thought that having a separate bool type would make the
above "if" statement illegal; but not if bools and ints are freely
interconvertable.  Shouldn't an explicit cast be required for those rare
occasions when you do need to convert between ints and bools.  So:

if ((bool)42)
    do_something;

would be required.


The same applies to converting pointers to bools.  In a context where a bool
is expected, only a bool should be accepted.  This is a fundamental principal
of type safety.  If you wish to pass in a pointer or an integer then you should
be required to cast it explicitly.


Do tell me if I'm up the spout!

Thanks
AdrianB

Whoops!  I messed that one up.

Just to clarify, I have no connection with the University of New Mexico,
Albuquerque; and my mail address is as below, not as above.  For some
reason "tin" seems to be ignoring my "Reply-To:".  I thought I would
just clarify first before fiddling, JIC!

Sorry,
AdrianB

--

=============================================
Adrian Brown, Shape Data (A division of EDS).

Please reply to: adrianb@ug.eds.com

>>>>> On 9 Dec 1993 12:14:45 GMT, brown@ug.eds.com (Adrian Brown) said:

> If all of my ints will freely convert to bools, and all of my bools
> will freely convert to ints how is there any real difference between
> having or not having a separate bool type?  I can still go:

> if (42)
>     do_something;

> I should have thought that having a separate bool type would make the
> above "if" statement illegal; but not if bools and ints are freely
> interconvertable.  Shouldn't an explicit cast be required for those rare
> occasions when you do need to convert between ints and bools.

You get the ability to overload functions etc. with respect to
bool/int, which is potentially useful.

There is, of course, nothing stopping compiler writers from adding an
(optional) warning for
      while (42) ...;
and similar constructs, and I've no doubt that they will, just as many
can already warn about
      if (i=2) ...;
and similar constructs, even though they're perfectly legal
(assuming int i).


--
Bruce                    Institute of Advanced Scientific Computation
bruce@liverpool.ac.uk    University of Liverpool

In article <2e6ktl$8q3@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
.>In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
.>>In short, I believe it would make sense to DISALLOW all arithmetic operations
.>>on type `bool'.  If someone wants to set a type bool variable to true, let
.>>them write:
.>>
.>>  my_bool_var = true;
.>
.>I agree completely, but I find the implicit conversion of int and
.>pointer to bool a bigger problem.  Unfortunately, there seems to be a
.>lot of C++ code that uses ++ on something that is conceptually a
.>Boolean type.  The committee decided to abandon some technical
.>advantages in order to preserve existing code (and coding practices,
.>let's not forget programmer compatibility).


I may be out of my depth here, but I'm not sure I understand the bit
about existing code getting broken if you did what RFG suggests.
Any integer in an existing program would surely still be allowed to
have ++ applied, whether it was a "conceptual Boolean" or not.  If
the programmer changes it to a type 'bool', it's not existing code
any more -- and I'm awfully sorry, but the "programmer compatibility"
argument sounds VERY thin against the type safety advantages that
a restricted set of appropriate operations might bring.

-- Alan Waldock, from but not on behalf of Intel Corporation
   ajw@guardian.intel.com

Why no &= for bool?

Andrew Koenig (ark@alice.att.com) wrote:
> No, the reasoning was ``well, if we implemented it according to the
> bool <--> int rules, it would do the wrong thing.''
       ^^
This direction is the source of the problem.

> [ Stuff deleted ]

> Now let's look at the Boolean case:

>  bool b = true;

>  b &= 2;

> If this were allowed at all, the only plausible interpretation
> would be to treat it the same way as

>  b = b & 2;

> Now, b & 2 is computed by converting b to int, yielding (1 & 2) or 0.
> This would be true even if it were written, say, this way:

>  b &= isupper(c);

> where the particular implementation of isupper happens to return 2.
> (If you think isupper should return a bool, substitute some other
> function that returns an int for historical reasons).

There are two points hiding here. The first is that & | ^ ~ are not defined
for bool (at least, they were not listed in the allowed operators list in the
post describing bool). Why not? && and || exist for the short-circuit
semantics. Why deny bool variables the non-short-circuit operators? Just as +
- * / exist for ints and floats (with appropriate promotions), why shouldn't &
| ^ ~ exist for bools and ints (again, with appropriate promotions)? This
would make the following legal:

 b &= b1;

And would eliminate the cast-to-int-and-back in the perfectly reasonable:

 b = b1 & b2;  // Note non-short-circuit expression

The second point is that all the above assignments, under current rules, cast
an int value to a bool. If the & | ^ ~ operators were allowed for bools, this
cast would be gone - except for the 'isupper' example above. Now, a cast from
an int to a bool is rather information-lossy. IMHO it should create a warning
every time it occurs, with the exception of the condition in an if, for or a
while statement and operands of && || and !. This will preserve the legality
of most current code that relies on implicit T* -> bool and int -> bool
conversions. As a first step, the conversion (outside the above contexts)
should be declared as a depreciated feature, so no code would actually break.

Providing an explicit cast is trivial. You just need to type two more
characters:

 b &= !!isupper(c); // If isupper returns an int for some reason

Which is really not too high a price for type safety, is it? Type safety used
to be one of C++ advantages over C. Allowing unrestricted int/T* -> bool
conversions would weaken this. Any chance it will be limited?

> So the real problem is that &= just isn't the right operation.

No, it is exactly the right operator, if only you don't need a short-circuit
operator.

> Well, what is?  I can readily imagine an operation

>  a &&= b

> being defined as equivalent to

>  (a = (a? b: false))

> except that `a' is evaluated only once, and similarly for ||=.

> However, that proposal is logically separable from the proposal
> for the Boolean type and neither Dag nor I felt it was useful
> enough to propose it.

Agreed. &&= is to &= what && is to &. Its usefulness is a completely separate
issue.

--

In article <2e7p0u$gvr@ornews.intel.com> ajw@ornews.intel.com (Alan
Waldock) writes:

|> In article <2e6ktl$8q3@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
|> .>In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
|> .>>In short, I believe it would make sense to DISALLOW all arithmetic operations
|> .>>on type `bool'.  If someone wants to set a type bool variable to true, let
|> .>>them write:

|> .>>  my_bool_var = true;

|> .>I agree completely, but I find the implicit conversion of int and
|> .>pointer to bool a bigger problem.  Unfortunately, there seems to be a
|> .>lot of C++ code that uses ++ on something that is conceptually a
|> .>Boolean type.  The committee decided to abandon some technical
|> .>advantages in order to preserve existing code (and coding practices,
|> .>let's not forget programmer compatibility).

|> I may be out of my depth here, but I'm not sure I understand the bit
|> about existing code getting broken if you did what RFG suggests.
|> Any integer in an existing program would surely still be allowed to
|> have ++ applied, whether it was a "conceptual Boolean" or not.  If
|> the programmer changes it to a type 'bool', it's not existing code
|> any more -- and I'm awfully sorry, but the "programmer compatibility"
|> argument sounds VERY thin against the type safety advantages that
|> a restricted set of appropriate operations might bring.

Except that in a lot of existing code, it *was* a bool.  And in a
header file somewhere, there was a typedef of bool to int.  The goal
was that such code would work by simply removing the typedef.

Personally, I probably would have prefered *not* allowing ++ on a
bool.  I would also have prefered actively deprecating the implicit
(and even the explicit) conversions, with the idea of making them
illegal in the next revision of the standard.  But I'm not the only
person in the universe; I think that Dag and Andy took other peoples
opinions into consideration too, and tried for a proposal which would
satisfy as many people as possible, and cause as few problems as
possible.  Which, of course, required a little bit of compromize wrt
elegance.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

rfg@netcom.com (Ronald F. Guilmette) writes [in part]:

>I would also like to mention that it seems altogether wrong to permit
>*any* "arithmetic" operations (e.g. increment) on this new `bool' type.
>This type is *not* (after all) supposed to represent arithmetic quantities,
>right?

>In short, I believe it would make sense to DISALLOW all arithmetic operations
>on type `bool'.  If someone wants to set a type bool variable to true, let
>them write:

>  my_bool_var = true;

>-- Ronald F. Guilmette, Sunnyvale, California -------------------------------

I agree wholemindedly with Ron.  From Dag's message earlier, it seems that:

 int nTrue = 1;
 int nFalse = 0;
 int nAlsoTrue = -1;
 bool b;

 b = nFalse;  // b is now false
 b++;   // b is now true
 b = nAlsoTrue;  // b is now true
 b++;   // b still true
 b = (nAlsoTrue + 1); // b is false
 b++;   // b is true again
 b--;   // illegal, but...
 b = true - 1;  // ... is apparently OK (b is false)
 b = false - 1;  // ... b is now true
 b = true + 1;  // ... b is still true
 b = false + 1;  // ... b is still true

The combinations that are possible are endless.  The point is that the
arithmetic operations are nonsensical on bools.  Why allow any of them?

JMO.

Shane
jsm@miteksys.com

In <comp.std.c++> mitek@nic.cerf.net (Mitek Systems) writes:
>
>I agree wholemindedly with Ron.  From Dag's message earlier, it seems that:
>
> int nTrue = 1;
> int nFalse = 0;
> int nAlsoTrue = -1;
> bool b;
>
> b = nFalse;  // b is now false
> b++;   // b is now true
> b = nAlsoTrue;  // b is now true
> b++;   // b still true
> b = (nAlsoTrue + 1); // b is false
> b++;   // b is true again
> b--;   // illegal, but...
> b = true - 1;  // ... is apparently OK (b is false)
> b = false - 1;  // ... b is now true
> b = true + 1;  // ... b is still true
> b = false + 1;  // ... b is still true
>
>The combinations that are possible are endless.  The point is that the
>arithmetic operations are nonsensical on bools.  Why allow any of them?

I think you misunderstand something fundamental here.  There is only
one "arithmetic" operator defined for bool: operator ++.

In all the other cases, e.g., "b = true + 1;" the arithmetic is done
with ints, and the value is then converted back to bool.  In
pseudo-code it becomes something like:

 int T1 = int(true)
 int T2 = T1 + 1
 b = bool(T2)

So all the cases you find nonsensical (as far as I can tell) follow
from the automatic conversion from int and pointer to bool.  I'm
inclined to agree, but the committee didn't.  My only defense is that
the original proposal deprecated this conversion.


     -- Dag

In <comp.std.c++> adrianb@ug.eds.com writes:
>
>if (42)
>    do_something;
>
>I should have thought that having a separate bool type would make the
>above "if" statement illegal; but not if bools and ints are freely
>interconvertable.  Shouldn't an explicit cast be required for those rare
>occasions when you do need to convert between ints and bools.

The problem is that you instantly break every current program the uses
"int" for boolean values.  You could argue in favour of warnings from
the compiler during a transition period, and I hope there will be such
compilers soon.

    -- Dag

In article <2e0d8sINN28u@early-bird.think.com>,
David Chase <chase@Think.COM> wrote:
>In article <27263@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
>|> In article <2ds58t$kon@news.delphi.com> bobkf@news.delphi.com (BOBKF@DELPHI.COM) writes:
>|> > > compound operators such as &= are *not* defined for bool left argument
>
>|> > And why not?
>
>|> Because & is a bitwise operator on integers, not a Boolean operator.
>|> If &&= existed, that would be the sensible operator to use for bool
>|> operatnds.
>
>I find this reasoning mystifying.  Since "&=" is an integer operation,
>and we've got rules for converting bools to integers (TRUE -> 1, FALSE
>-> 0) and rules for converting integers to bools (!= 0 -> TRUE, =0 ->
>FALSE) it would seem that this operation could not only be defined,
>but that it would actually be useful (that is, do what you expect),
>and would also be easily optimized.  I hope the reasoning behind this
>decision was not "well, it might be expensive if naively implemented
>according to the bool <--> int rules, so we'll just leave it
>undefined".

I think the decision was made more on consistency grounds.  The "&="
family of operators all do very integer-oriented things.  Obviously,
any definition involving promoting the lhs of the operator is not
feasible because the result of such any implicit promotion is not an
lvalue.  I would have been happier if they had decided to add operators
&&= and ||=, since they provide a nice completion of the set of compound
operators and make the bool type support more "complete", but I expect
that those operators will be added eventually in any case.

- Brad
--------------------------------------------------------------------------
+ Brad Daniels                  | Until you can prove unequivocally that +
+ Biles and Associates          | you're arguing epistemology with me,   +
+ These are my views, not B&A's | I won't argue epistemology with you.   +
--------------------------------------------------------------------------

In article <2e7p0u$gvr@ornews.intel.com> ajw@ornews.intel.com (Alan Waldock) writes:
>I may be out of my depth here, but I'm not sure I understand the bit
>about existing code getting broken if you did what RFG suggests.
>Any integer in an existing program would surely still be allowed to
>have ++ applied, whether it was a "conceptual Boolean" or not.  If
>the programmer changes it to a type 'bool', it's not existing code
>any more -- and I'm awfully sorry, but the "programmer compatibility"
>argument sounds VERY thin against the type safety advantages that
>a restricted set of appropriate operations might bring.

I disagree.

If changing a variable to type bool is going to force the programmer to
examine and update all the uses of the variable, he's more than likely not
going to bother updating the declaration.  The bool proposal allows a
programmer to change the declaration immediately, and then start taking
advantage of the special features of bools incrementally.
--
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

In article <2e74rlINNl97@lynx.unm.edu> adrianb@ug.eds.com writes:

> By "promotes" I take it that you mean that they will automatically
> convert where needed.  If this is so, then does this not break one of
> the principal reasons for having a separate "bool" type -  namely
> that of type safety?  If all of my ints will freely convert to bools,
> and all of my bools will freely convert to ints how is there any
> real difference between having or not having a separate bool type?

Sure.

 1. It allows overloading on bools.

 2. Compilers can be made to warn about dubious usages.

 3. You don't have to worry about having all your libraries define
    `bool' incompatibly, the way they do now.

> I can still go:
>
> if (42)
>     do_something;

Sure.  To do otherwise would be gratuitously breaking existing code.
I just don't think that's something the committee is allowed to do.

However, vendors who think this is dubious practice are allowed to warn
about it, as they are about all dubious practices.

> Do tell me if I'm up the spout!

What you suggest would be a fine idea if we were desigining C++ from scratch.
As it is, though, we have an obligation to combine maximum utility with
minimum damage.
--
    --Andrew Koenig
      ark@research.att.com

rfg@netcom.com (Ronald F. Guilmette) writes:

>I would also like to mention that it seems altogether wrong to permit
>*any* "arithmetic" operations (e.g. increment) on this new `bool' type.

I agree with respect to all the other arithmetic operations except
increment.  For increment, I think that compilers should issue a warning,
but allow it.  The reason for this is to make conversion from pre-standard
C++ to ANSI/ISO C++ easier.

>Note also that if the intent is that type `bool' variables should hold
>*only* the quantities true or false (presumably represented by 1 and 0
>respectively) then an actual hardware-level "increment" is most definitely
>NOT the proper way to set a `bool' to the value true.  In particular,
>an actual hardware-level increment of a `bool' variable which already
>has the value true (1) would result in a new value (2) which is not even
>a valid `bool' value.

I think you have missed the real reason for allowing a boolean increment
operator.  It doesn't have anything to do with hardware-level increments.

>I see no point in introducing a new boolean type (presumably as a better
>alternative than the old reliable ints) if programmers will still be
>permitted to (mistakenly) blur the distinction between arithmetic operations
>and strictly boolean operations.

There are two major benefits:

 (1) It reduces clashes with libraries that each define their
     own boolean type

 (2) It makes it easy for compilers to warn about int/bool implicit
     conversions, and easy for users to demand that their compilers
     implement this warning, and hence provides a way for those
     who want stricter type-checking for booleans to get what they
     want.

In the long-term, int/bool implicit conversion could be depreciated by
the standard, which would provide a path towards strict type-checking
for booleans in C++.  I don't see this happening in the near future ---
after all, this would break a _lot_ of code --- but by allowing yet not
requiring warnings for int/bool implicit conversions, the C++ committee
has left it up the the marketplace to decide whether C++ users want
strict type-checking for booleans.  This is a Good Idea, IHMO.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In article <1993Dec9.140509.18602@wisipc.weizmann.ac.il> oren@pashosh.weizmann.ac.il (Ben-Kiki Oren) writes:

> There are two points hiding here. The first is that & | ^ ~ are not defined
> for bool (at least, they were not listed in the allowed operators list in the
> post describing bool). Why not? && and || exist for the short-circuit
> semantics. Why deny bool variables the non-short-circuit operators?

Because the whole point of the proposal is to make it possible for most
programs that today say

 typedef int bool;

to continue to work the same way without the typedef, or to fail in clearly
identifiable ways.

Today if someone says

 typedef int bool;

 bool b = 1;
 b &= 2;

then the value of b is zero.  Clearly b is not being used as a Boolean.
So we would like, if the typedef disappears, for this program to fail.

> Providing an explicit cast is trivial. You just need to type two more
> characters:

>  b &= !!isupper(c); // If isupper returns an int for some reason

> Which is really not too high a price for type safety, is it?

Yes it is.
--
    --Andrew Koenig
      ark@research.att.com

In article <CHrtzI.HtF@biles.com> daniels@biles.com (Brad Daniels) writes:

> I think the decision was made more on consistency grounds.  The "&="
> family of operators all do very integer-oriented things.

Exactly.

> I would have been happier if they had decided to add operators
> &&= and ||=, since they provide a nice completion of the set of compound
> operators and make the bool type support more "complete", but I expect
> that those operators will be added eventually in any case.

Perhaps.  So far no one has proposed them.  Moreover, I suspect that if the
original proposal had contained &&= and ||=, it would have been voted down.
--
    --Andrew Koenig
      ark@research.att.com

mitek@nic.cerf.net (Mitek Systems) writes:

> b = true - 1;  // ... is apparently OK (b is false)
> b = false - 1;  // ... b is now true
> b = true + 1;  // ... b is still true
> b = false + 1;  // ... b is still true
>
>The combinations that are possible are endless.  The point is that the
>arithmetic operations are nonsensical on bools.  Why allow any of them?

Because existing code is important.  The committee doesn't want to
gratuitously break everyone's programs when there is little benefit.

Currently, code like

 int num_gt_zero = (x > 0) + (y > 0) + (z > 0);

is legal, and is doubtless used in real C++ programs on occaision.
Disallowing the conversion from bool to int would make code like this
illegal, which would break people's programs.
Similarly, code like

 int x;
 ...
 if (x) { ... }

is very common, and disallowing the conversion from int to bool would
make that code illegal.

Even if you're willing to break existing code, you need to weigh it up
against the expected benefit.  With the committee's proposal, compilers
are free to _warn_ about these implicit conversions.  Requiring the
compiler to report an _error_ would not provide any benefits that an
optional warning wouldn't.  Furthermore the warning would be very easy
to implement.  So if you want type-safety for booleans, then just lobby
your compiler vendor to implement this warning.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

chase@Think.COM (David Chase) writes:

>|> If &&= existed, that would be the sensible operator to use for bool
>|> operatnds.

>I find this reasoning mystifying.  Since "&=" is an integer operation, ...

The semantics of "lhs &&= rhs" would, I presume be:

if (!lhs) lhs=rhs;


ie. don't evaluate rhs (or side-effects) unnecessarily.


Whether this is useful, or just dangerous, I don't know.

--
Warwick

I suggested:

1) a bool is (almost) an _integer type_. false and true are constants of
   this type. No other values exist. A bool can be promoted just like any
   integer type (bool -> char -> short -> int -> ...) In which case true -> 1,
   false -> 0. This allows bools to be used (almost) wherever an integer is
   used, so we avoid breaking potentially useful code.

Two special rules apply to bools:

2) As a special case, the conversion T -> bool (T == (T)0) is allowed
   _only_ for types for which (T)0 makes sense (char short int long float
   double T*) and _only_ in an if, for or while condition, or for operands of
   && || and !. This allows for the current uses, so we don't break code.

   Anywhere else this conversion is illegal, and produces an error (I'll
   settle for a warning if too much existing code is involved). This breaks
   the code we want to break.

3) As a special case, applying arithmetic operators + - * / to bools is
   illegal (you can do it if you are mixing a bool with another arithmetic
   type). += -= *= /= and -- should definitely be banned for bools. ++ might
   be allowed, if code depends on it, but it should at least be depreciated.
   This breaks the rest of the code we want to break.

To make bool even more like an 'integer type' you might avoid (3) by requiring
that + - * / will yield reasonable results when applied to bools... * is &, +
and - are ^, and / is either a no-op (if dividing by true) or undefined (if
dividing by false). Personally, I'd rather ban them. But if completeness and
orthogonality are deemed more important then avoidance of special rules (that
will be the day...), you could do it this way.

Andrew Koenig (ark@alice.att.com) wrote:
> In article <1993Dec9.140509.18602@wisipc.weizmann.ac.il> I wrote:
> > There are two points hiding here. The first is that & | ^ ~ are not defined
> > for bool (at least, they were not listed in the allowed operators list in the
> > post describing bool). Why not? && and || exist for the short-circuit
> > semantics. Why deny bool variables the non-short-circuit operators?

> Because the whole point of the proposal is to make it possible for most
> programs that today say

>  typedef int bool;

> to continue to work the same way without the typedef, or to fail in clearly
> identifiable ways.

And how does my suggestion fail to satisfy the above? Can you please give an
example?

> Today if someone says

>  typedef int bool;

>  bool b = 1;
>  b &= 2;

> then the value of b is zero.  Clearly b is not being used as a Boolean.
> So we would like, if the typedef disappears, for this program to fail.

And it does, under my suggestion. Because 'b &= 2' becomes:

 b = (bool)((int)b & 2)

and under rule (2) above the conversion int -> bool is flagged as an error.
And if the programmer wants to fix this code:

> > Providing an explicit cast is trivial. You just need to type two more
> > characters:

> >  b &= !!isupper(c); // If isupper returns an int for some reason

> > Which is really not too high a price for type safety, is it?

> Yes it is.

I don't get it. We both agree that the unmodified version

 b &= int_expr

should be illegal. So to make it legal, we have to do _something_ to the code.
In my way, you pay two characters. In your way, you have to say:

 b = int_expr && b

Which is a _higher_ price then saying:

 b &= !!int_expr

Now as for type safety. The current bool rules allow monstrosities such as:

 int x = 19, y = 23;
 bool b = x * 7 + y / 18 - getchar();
 b = x * b + y & b;
 b = b - b - b / b + b * b;

Now, is 'b' clearly used as a Boolean in the above statements?

It seems to me you pay a higher price, get less type safety, allow + - * / on
bools, which have no meaning, but disallow & | ~ which do have a clear
meaning... IMVHO once it is implemented this will become yet another source
for recurrent threads in comp.lang.c++, like the for scoping rule, the
definition of NULL, and a few others I could mention (weep).

       Oren.

--

In article <2ds58t$kon@news.delphi.com> bobkf@news.delphi.com (BOBKF@DELPHI.COM) writes:

> > compound operators such as &= are *not* defined for bool left argument

> And why not?

Because & is a bitwise operator on integers, not a Boolean operator.
If &&= existed, that would be the sensible operator to use for bool
operatnds.
--
    --Andrew Koenig
      ark@research.att.com

In article <27263@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
|> In article <2ds58t$kon@news.delphi.com> bobkf@news.delphi.com (BOBKF@DELPHI.COM) writes:
|> > > compound operators such as &= are *not* defined for bool left argument

|> > And why not?

|> Because & is a bitwise operator on integers, not a Boolean operator.
|> If &&= existed, that would be the sensible operator to use for bool
|> operatnds.

I find this reasoning mystifying.  Since "&=" is an integer operation,
and we've got rules for converting bools to integers (TRUE -> 1, FALSE
-> 0) and rules for converting integers to bools (!= 0 -> TRUE, =0 ->
FALSE) it would seem that this operation could not only be defined,
but that it would actually be useful (that is, do what you expect),
and would also be easily optimized.  I hope the reasoning behind this
decision was not "well, it might be expensive if naively implemented
according to the bool <--> int rules, so we'll just leave it
undefined".

At code generation/optimization time) if the bools have canonical
representation (0, 1) then the operation is (Sparc example)

  "x &= y" ==> "and x,y,x"

if one is canonical, the other not, then you can use condition
code hacks to get a canonical.

  "canon_x &= non_canon_y" ==> subcc %g0,y,%g0
                               subx  %g0,%g0,t
                               and   x,t,x

If x is not canonical, this can still be used to get a correct,
non-canonical, answer.  By canonical/noncanonical, I refer to the
run-time representation chosen for the values.  Obviously, there
are situations in which it may be more efficient to not bother
with the 0/1 representation if you are not actually treating the
bool as an integer.

Other machines (e.g., Power family) may choose to stuff these
into condition codes, or whatever happens to be most convenient.
Another choice might be to use the non-canonical representation
of LSB+other junk, in which case the straight machine-code
operations should work fine (best choice of a non-canonical
representation depends upon which ops you are most common, and
where).

However, I generally am quite happy to see this.  Better late than
never.

David Chase
speaking for myself, not my employer.

ark@alice.att.com (Andrew Koenig) writes:

>In article <2ds58t$kon@news.delphi.com> bobkf@news.delphi.com (BOBKF@DELPHI.COM) writes:

>> > compound operators such as &= are *not* defined for bool left argument

>> And why not?

>Because & is a bitwise operator on integers, not a Boolean operator.
>If &&= existed, that would be the sensible operator to use for bool
>operatnds.

How Pascal-like! (Read, "ugh.") So as a consequence, "bool" is less usable
than int used to hold boolean results. Yes, &&= would be a sensible
choice; so why doesn't it exist?

Bob Foster
objfactory@aol.com

In article <27263@alice.att.com> ark@alice.UUCP () writes:
>In article <2ds58t$kon@news.delphi.com> bobkf@news.delphi.com (BOBKF@DELPHI.COM) writes:
>
>> > compound operators such as &= are *not* defined for bool left argument
>
>> And why not?
>
>Because & is a bitwise operator on integers, not a Boolean operator.
>If &&= existed, that would be the sensible operator to use for bool
>operatnds.

Perhaps &&= and ||= *should* now exist... now that the language has a
primitive built-in boolean type!

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <2e0htq$hqg@news.delphi.com> bobkf@news.delphi.com (BOBKF@DELPHI.COM) writes:

> How Pascal-like! (Read, "ugh.") So as a consequence, "bool" is less usable
> than int used to hold boolean results. Yes, &&= would be a sensible
> choice; so why doesn't it exist?

Because no one wanted it badly enough to propose it.
--
    --Andrew Koenig
      ark@research.att.com

In article <2e0d8sINN28u@early-bird.think.com> chase@Think.COM (David Chase) writes:

> I find this reasoning mystifying.  Since "&=" is an integer operation,
> and we've got rules for converting bools to integers (TRUE -> 1, FALSE
> -> 0) and rules for converting integers to bools (!= 0 -> TRUE, =0 ->
> FALSE) it would seem that this operation could not only be defined,
> but that it would actually be useful (that is, do what you expect),
> and would also be easily optimized.  I hope the reasoning behind this
> decision was not "well, it might be expensive if naively implemented
> according to the bool <--> int rules, so we'll just leave it
> undefined".

No, the reasoning was ``well, if we implemented it according to the
bool <--> int rules, it would do the wrong thing.''

There are some C compilers out there with the following bug:

 int n = 4;

 n *= 1.3; /* n should be 5, but might be 4 */

The reason that n should be 5 is that

 n *= 1.3;

is supposed to be equivalent to

 n = n * 1.3;

Now, n * 1.3 is clearly close to 5.2, which when assigned to n
should surely be 5.  However, some compilers take the shortcut
of converting 1.3 to int, yielding 1, and then multipling 4 by 1
to give 4.

Now let's look at the Boolean case:

 bool b = true;

 b &= 2;

If this were allowed at all, the only plausible interpretation
would be to treat it the same way as

 b = b & 2;

Now, b & 2 is computed by converting b to int, yielding (1 & 2) or 0.
This would be true even if it were written, say, this way:

 b &= isupper(c);

where the particular implementation of isupper happens to return 2.
(If you think isupper should return a bool, substitute some other
function that returns an int for historical reasons).

So the real problem is that &= just isn't the right operation.

Well, what is?  I can readily imagine an operation

 a &&= b

being defined as equivalent to

 (a = (a? b: false))

except that `a' is evaluated only once, and similarly for ||=.

However, that proposal is logically separable from the proposal
for the Boolean type and neither Dag nor I felt it was useful
enough to propose it.
--
    --Andrew Koenig
      ark@research.att.com

Hidden at the end of a long article on the IOStream standard,
maxtal@physics.su.OZ.AU (John Max Skaller) writes:

>The committee just adopted a new data type -- bool -- as part of
>the core language.

Is this really true???
Has the committee finally seen the light? ;-)
Can someone please post more details about this?

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

>maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>>The committee just adopted a new data type -- bool -- as part of
>>the core language.

Executive summary
=================

"bool" is a unique signed integral type, just as the "wchar_t" is a
unique unsigned type.

There are two built-in constants of this type: "true" and "false".

Operator "++" is defined for "bool"; it always sets its
operand to "true".  This operator is an anachronism, and its use
is deprecated.

A "bool" value may be converted to "int" by promotion, taking "true"
to one and "false" to zero.

A numeric or pointer value is automatically converted to "bool" when
needed.

When converting a numeric or pointer value to "bool", a zero value
becomes "false"; a non-zero value becomes "true".

The built-in operators "&&", "||", and "!" are changed to take "bool"
values as their arguments and return "bool" results.

The relational operators "<", ">", "<=", ">=", "==", and "!=" are
changed to yield a "bool" result.

Expressions used as conditions in "if", "for", "while", or "do"
statements or as the first operand of a "?:" expression, are
automatically converted to "bool".

In article <9333701.23487@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

> Is this really true???
> Has the committee finally seen the light? ;-)
> Can someone please post more details about this?

Yes, it's really true.  The proposal was by me and Dag Bruck.  It was
accepted by about a 2:1 vote, which mirrors surprisingly accurately
how I feel about the proposal -- I think it's a good idea but not
overwhelmingly so.

Very briefly,

 the type is called bool

 the bool values are called true and false

 converting numeric or pointer type to bool takes 0 to false
 and anything else to true

 bool promotes to int, taking false to 0 and true to 1

 places such as `if' and `while' statements, as well as
 the operands of && || ! (but not & | ~) are now converted
 to bool

 all operators that conceptulally return truth values return bool

 compound operators such as &= are *not* defined for bool left argument
--
    --Andrew Koenig
      ark@research.att.com

ark@alice.att.com (Andrew Koenig) writes:

>       ...
> places such as `if' and `while' statements, as well as
> the operands of && || ! (but not & | ~) are now converted
> to bool
>       ...
> compound operators such as &= are *not* defined for bool left argument

And why not?

Bob Foster
objfactory@aol.com