I don't know if this has been discussed before, and I couldn't find a "search" in this forum, so...

Is "bit" D's boolean type? If it is, OK. But, if some people use bit, others use int and others define a custom type, i'm afraid D will follow C's path (Let the developer choose its boolean type. Then every library has a typedef for bool or BOOL. After the mess, define a type with a strange name like _Bool...)

It was origionally bit, but bool was recently added as an alias to bit.

"w" <w_member@pathlink.com> wrote in message news:bjg0d7$nke$1@digitaldaemon.com...
> I don't know if this has been discussed before, and I couldn't find a
"search"
> in this forum, so...
>
> Is "bit" D's boolean type? If it is, OK. But, if some people use bit,
others use
> int and others define a custom type, i'm afraid D will follow C's path
(Let the
> developer choose its boolean type. Then every library has a typedef for
bool or
> BOOL. After the mess, define a type with a strange name like _Bool...)
>
>

bit was originally to be used. bool is now an alias for bit.

There are *several* people who do not like this, but sadly Walter's not one of them. Not that we don't keep trying to convince him every now and than.

I personally think that bool should be a distinct type, of the size of int, and which cannot engage in implicit conversions to and from integer types. Sadly, my sway is marginal, at best. :(

"w" <w_member@pathlink.com> wrote in message news:bjg0d7$nke$1@digitaldaemon.com...
> I don't know if this has been discussed before, and I couldn't find a
"search"
> in this forum, so...
>
> Is "bit" D's boolean type? If it is, OK. But, if some people use bit,
others use
> int and others define a custom type, i'm afraid D will follow C's path
(Let the
> developer choose its boolean type. Then every library has a typedef for
bool or
> BOOL. After the mess, define a type with a strange name like _Bool...)
>
>

I like bool as a bit rather than as an int because by definition a bool is limited to a set of two values, but an int can hold oh so many more.

My opinion is that with a bool the two operations not (!) and complement (~) should return the same value, which is not always true with ints. Of course maybe it doesn't make sense to perform complement on bools anyway, but I see no reason not to allow it.

John Boucher
The King had Humpty pushed.

[Apologies up-front for the shameless egotism in trying out my new signature. Sorry chaps.]

The argument against bool as a bit is that a bit cannot have its address taken. That's an acceptable limitation, since everyone understands bits are a sub-unit of the "lowest addressable unit", i.e. a byte. However, it's not in the least bit reasonable for a bool, and will lead to a profusion of Bool, boolean, Boolean, _Bool types.

The argument against bool as a small type (i.e. 8 or 16-bits) is that there are unavoidable inefficiencies in the following

 int i = . . .;
 bool b = i; // The compiler must replace this with bool b = i != 0;

I grant you this is less compelling, but this is a serious (from efficiency) flaw of C++, and D is supposed to be answering the flaws in C++ - especially the easy ones - so I just don't think doing the same thing is acceptable.

Naturally if implicit conversions to and from integers are disallowed this kind of thing goes away. If people want implicit conversions, then sizeof(bool) is an important matter.

Either way, it's about time we heard from the big guy on this. Walter?

Oh, as for ~ I think it's entirely inappropriate to have a bit-wise operator on a type whose *entire* reason for being is to represent logical notions. No ~ for bool for me please. (Another reason to move away from it being an alias for bit.) The reason to disallow it is simple, it is not appropriate. Languages are not suffering from a lack of malapplicable operators. Quite the reverse. And I say this as one who has formerly committed all kinds of transgressions in C++ over the years. I once implemented the ++ operator for a string class!

-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"An Englishman by birth, a Yorkshireman by the grace of God" -- Michael Gibbs

----------------------------------------------------------------------------
---



"John Boucher" <John_member@pathlink.com> wrote in message news:bjgsj3$1vdf$1@digitaldaemon.com...
> I like bool as a bit rather than as an int because by definition a bool is limited to a set of two values, but an int can hold oh so many more.
>
> My opinion is that with a bool the two operations not (!) and complement
(~)
> should return the same value, which is not always true with ints. Of
course
> maybe it doesn't make sense to perform complement on bools anyway, but I
see no
> reason not to allow it.
>
> John Boucher
> The King had Humpty pushed.

"Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bjgv8a$23cu$1@digitaldaemon.com...
> Languages are not suffering from a lack of malapplicable operators. Quite the reverse. And I say this as one who has formerly committed all kinds of transgressions in C++ over the years. I once implemented the ++ operator
for
> a string class!

In case you thought you were in for some prize, I've heard that someone was as crazy as to implement bitshift operators on I/O streams!! :)

BTW, what in the world did that ++ do when applied to a string? Just curious...

Ric

"Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in message news:bjhcei$2nku$2@digitaldaemon.com...
> "Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bjgv8a$23cu$1@digitaldaemon.com...
> > Languages are not suffering from a lack of malapplicable operators.
Quite
> > the reverse. And I say this as one who has formerly committed all kinds
of
> > transgressions in C++ over the years. I once implemented the ++ operator
> for
> > a string class!
>
> In case you thought you were in for some prize, I've heard that someone
was
> as crazy as to implement bitshift operators on I/O streams!! :)
>
> BTW, what in the world did that ++ do when applied to a string? Just curious...

This is one of several of my former C++ criminality that're going into Appendix B of my book. You'll have to buy it! ;)

The last time this came up, I posted some comments about a line of thinking that says bool arguments are overused.  If you buy into that argument (and it does have some merit), then not being able to take the address of bool isn't so bad.

   Dan

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bjgv8a$23cu$1@digitaldaemon.com...
> [Apologies up-front for the shameless egotism in trying out my new signature. Sorry chaps.]
>
> The argument against bool as a bit is that a bit cannot have its address taken. That's an acceptable limitation, since everyone understands bits
are
> a sub-unit of the "lowest addressable unit", i.e. a byte. However, it's
not
> in the least bit reasonable for a bool, and will lead to a profusion of Bool, boolean, Boolean, _Bool types.
>
> The argument against bool as a small type (i.e. 8 or 16-bits) is that
there
> are unavoidable inefficiencies in the following
>
>  int i = . . .;
>  bool b = i; // The compiler must replace this with bool b = i != 0;
>
> I grant you this is less compelling, but this is a serious (from
efficiency)
> flaw of C++, and D is supposed to be answering the flaws in C++ -
especially
> the easy ones - so I just don't think doing the same thing is acceptable.
>
> Naturally if implicit conversions to and from integers are disallowed this kind of thing goes away. If people want implicit conversions, then sizeof(bool) is an important matter.
>
> Either way, it's about time we heard from the big guy on this. Walter?
>
> Oh, as for ~ I think it's entirely inappropriate to have a bit-wise
operator
> on a type whose *entire* reason for being is to represent logical notions. No ~ for bool for me please. (Another reason to move away from it being an alias for bit.) The reason to disallow it is simple, it is not
appropriate.
> Languages are not suffering from a lack of malapplicable operators. Quite the reverse. And I say this as one who has formerly committed all kinds of transgressions in C++ over the years. I once implemented the ++ operator
for
> a string class!
>
> -- 
> Matthew Wilson
>
> STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
> Contributing editor, C/C++ Users Journal
> (www.synesis.com.au/articles.html#columns)
>
> "An Englishman by birth, a Yorkshireman by the grace of God" -- Michael Gibbs
>
> --------------------------------------------------------------------------
--
> ---
>
>
>
> "John Boucher" <John_member@pathlink.com> wrote in message news:bjgsj3$1vdf$1@digitaldaemon.com...
> > I like bool as a bit rather than as an int because by definition a bool
is
> > limited to a set of two values, but an int can hold oh so many more.
> >
> > My opinion is that with a bool the two operations not (!) and complement
> (~)
> > should return the same value, which is not always true with ints. Of
> course
> > maybe it doesn't make sense to perform complement on bools anyway, but I
> see no
> > reason not to allow it.
> >
> > John Boucher
> > The King had Humpty pushed.
>
>

I thought Walter made it so that you can take the address of a bit and pass it by reference?

Bool should be a 1-bit type that the compiler can store in a byte or int if it wants.  You should not have any guarantee in the language regarding the size of bool.  If you, the programmer, need to know, use the .size property.

Sean

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bjgv8a$23cu$1@digitaldaemon.com...
> The argument against bool as a bit is that a bit cannot have its address taken. That's an acceptable limitation, since everyone understands bits
are
> a sub-unit of the "lowest addressable unit", i.e. a byte. However, it's
not
> in the least bit reasonable for a bool, and will lead to a profusion of Bool, boolean, Boolean, _Bool types.
>
> The argument against bool as a small type (i.e. 8 or 16-bits) is that
there
> are unavoidable inefficiencies in the following
>
>  int i = . . .;
>  bool b = i; // The compiler must replace this with bool b = i != 0;
>
> I grant you this is less compelling, but this is a serious (from
efficiency)
> flaw of C++, and D is supposed to be answering the flaws in C++ -
especially
> the easy ones - so I just don't think doing the same thing is acceptable.
>
> Naturally if implicit conversions to and from integers are disallowed this kind of thing goes away. If people want implicit conversions, then sizeof(bool) is an important matter.

If the language is strongly typed, shouldn't this produce a compile-time error? I hope it would. Why add a bool type except to type it strongly?

> int i = . . .;
> bool b = i; // The compiler must replace this with bool b = i != 0;

John Boucher
The King had Humpty pushed.