Walter wrote:
> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:bgmfml$2fr1$1@digitaldaemon.com...
> 
>>>I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as
>>>there is the implication that there is none of this tri-state confusion
>>>nonsense we find in C, but others obviously don't see it that way.
>>
> "bool" is
> 
>>>used in C and C++.
>>
>>"boolean" describes its semantics without bringing in either unfortunate
>>comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).
> 
> 
> What wrong impression does bit give? I'm a bit (!) flummoxed as to why
> people find bit so distasteful.
> 
> 

Hi, Walter.

By adding the alias for bool in a core library (is it in Phobos?), you've made me happy.  I just didn't want to deal with resolving conflicting definition of 'bool', as I did in C and C++.

Bill

Walter wrote
>
>I've actually done code dealing with such issues (and I've even written FPGA design tools), and I find it works best to simply write the shift and mask operations custom to the job.

Oh my goodness - those are one of the major bug nests in embedded work.  How nice it would be to just 'slice' a bit array instead.

About the boolean type I would not mind its absence if D were not a DbC language.  But in such a language, the missing boolean type is like a missing thumb.  Since DbC is built into the language, booleans should be built into it as well - they go together.  C/C++ doesn't have DbC so it's a different story.

Mark

Burton Radons wrote:
> Matthew Wilson wrote:
> 
>> Wearing my heretical pragmatist hat, may I pose the question: why do we have
>> a bit type? I am at a loss to think why it is useful (or more useful than
>> bit fields).
> 
> 
> Its semantics are for boolean.  It should be renamed - I want "boolean", as "bool" is just lazy.  Walter, is there any reason why it hasn't been renamed?
> 
I guess I'm lazy, because I like bool better than
boolean. I'd have to retrain my fingers to type
the extra "ean" letters. My eyes too, because I'm
pretty used to seeing "bool", not boolean.

However, here's my opinion. Walter is doing all the
work of creating the language and developing the
compiler. If he likes bit, I can type bit. If there
is a real technical reason for a boolean type, I'd
be happy to type bool (or boolean if I must.) Mostly
I think we are splitting hairs (or bits?) here.

"Frank Wills" <fdwills@sandarh.com> wrote in message news:bgsm61$2cd9$1@digitaldaemon.com...
> Burton Radons wrote:
> > Matthew Wilson wrote:
> >
> >> Wearing my heretical pragmatist hat, may I pose the question: why do
> >> we have
> >> a bit type? I am at a loss to think why it is useful (or more useful
than
> >> bit fields).
> >
> >
> > Its semantics are for boolean.  It should be renamed - I want "boolean", as "bool" is just lazy.  Walter, is there any reason why it hasn't been renamed?
> >
> I guess I'm lazy, because I like bool better than
> boolean. I'd have to retrain my fingers to type
> the extra "ean" letters. My eyes too, because I'm
> pretty used to seeing "bool", not boolean.

I don't care whether it's bool or boolean. Arguably, since we are using C's terse naming, i.e. int rather than integer, then we should go for bool. It'll also save fatuous editing when porting between C++ and D.

But overall, don't care.

> However, here's my opinion. Walter is doing all the
> work of creating the language and developing the
> compiler. If he likes bit, I can type bit. If there
> is a real technical reason for a boolean type, I'd
> be happy to type bool (or boolean if I must.) Mostly
> I think we are splitting hairs (or bits?) here.

Not so. The differences are very important, for the reasons already mentioned several times. We *must* have bool/boolean type, it *must* not be bit-size, and it *should* be the same size as int.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bgpj3f$2gh8$1@digitaldaemon.com...
> That it can be forced to behave similar to a bit using a lot of casting and support code doesn't change the fact that it's NOT A BIT.

All it would be is:
    bit b = cast(bit)(d & 1);

"Bill Cox" <bill@viasic.com> wrote in message news:3F310C79.7080703@viasic.com...
> By adding the alias for bool in a core library (is it in Phobos?), you've made me happy.  I just didn't want to deal with resolving conflicting definition of 'bool', as I did in C and C++.

I think you might be the only one happy with that besides myself <g>.

>
> Not so. The differences are very important, for the reasons already mentioned several times. We *must* have bool/boolean type, it *must* not
be
> bit-size, and it *should* be the same size as int.

I disagree with the latter part of that.

we *must* have a boolean-type with boolean semantics
it *can* be implemented in *any* way bit, byte, int, long as long as its
passable in,out,inout and you can have a pointer to it. if declared as a
extern( C ) boolean b; then it *must* be implemented as an int (same for
boolean params in extern(C or Windows) functions.
int i;
cast(boolean)i  equiv to i!=0

if there is a 'bit' type is should be have 'bit' semantics, which means it
_can_ be "in" only as bit pointers are extra work.
cast(bit)i equiv to i&1  (in line with byte and short cast operators).

"Walter" <walter@digitalmars.com> wrote in message news:bgmnb5$2n2b$1@digitaldaemon.com...
>
> "Burton Radons" <loth@users.sourceforge.net> wrote in message news:bgmfml$2fr1$1@digitaldaemon.com...
> > > I've put a bool alias for bit in 0.69. I found "bit" to be appealing,
as
> > > there is the implication that there is none of this tri-state
confusion
> > > nonsense we find in C, but others obviously don't see it that way.
> "bool" is
> > > used in C and C++.
> > "boolean" describes its semantics without bringing in either unfortunate
> > comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).
>
> What wrong impression does bit give? I'm a bit (!) flummoxed as to why people find bit so distasteful.

Mostly they're used to typing 'bool' instead.  ;)  If it's not in the base language, there *will* end up being many incompatible and conflicting definitions of bool.  Once this starts proliferating it will be impossible to add a standard bool type without breaking existing code, as all builtin types are keywords.

Personally I don't mind using 0 and 1 instead of true and false;  it's shorter to type.  Pesky automatic conversions may bite you though.  I guess people just want a distinct boolean type that's incompatible with int types, though explicit conversions should still be possible.  Helps catch certain kinds of errors.

I think the biggest reason may be that you can't use bit as an out parameter.  Last I checked you couldn't have pointers to bit either, but I've heard rumors here that it is now possible.

Sean

"BenjiSmith" <BenjiSmith_member@pathlink.com> wrote in message news:bgmpoe$2ph4$1@digitaldaemon.com...
> I don't know if anybody else is on the same page as me, but these are the reasons that I'd like to have a boolean type instead of just a bit type.
Of
> course, I'd like to have _both_ bits and booleans (please just don't call
it
> 'bool'), since bits (and bit arrays) could be useful for their own
purposes. But
> I'd prefer to keep my true/false values in a boolean than in a bit.

FWIW, I prefer the shortened name 'bool'.  For one thing, that's what C and C++ people will expect, and what they're used to.  Gives D a bit more compatibility with those languages.

It's the same reason we don't write out 'integer' ala Pascal.  When you write 'int' everyone knows what you mean, and it's shorter to type.

D is derived from C, not Pascal, and it should stick closer to C conventions unless there are good reasons to stray.

Sean

"Derek Parnell" <derek.parnell@no.spam> wrote in message news:oprtesn7jf59ej19@news.digitalmars.com...
> Its a conceptual thing mainly. A 'bool' is a STATE but a 'bit' holds a
data
> value. A 'bit' must be mapped to a RAM location but a 'bool' doesn't (I'm not talking about implementatin here - just logical/conceptual stuff).

That's just not true.  There is nothing that says a bit has to be in a memory location:  It could just as easily dwell in a register or even in a CPU flag, if only transiently.

> Conceptually, you can do arithmetic with bits but it doesn't make sense to add up three 'bools', for example.

True enough, the operators that apply to bool are different than the ones that apply to bit.  Logical ops could apply to both.  Seems the main difference is that bit is compatible mathematically with integers, and bool is not.

However if you think about it, AND is alot like multiply or minimum, OR is alot like maximum, XOR is alot like addition or subtraction.  One could define operations that make sense on both.  It would take great care to do so, however, and probably people would end up confused.

> When it comes to implementing a bool, you would probably wise to choose a data storage element that is fast - such as an int. However, you might serious consider disallowing arithmetic functionality, include
comparisions
> to numeric values. It doesn't make much sense if test if a 'bool' is
larger
> than 5, for example.
>
> As you mention above, a 'bit' can be used to implement a 'bool'. However,
a
> 'bit' has more functionality behind it than a 'bool' needs or even
wants. --
>  Derek

Yep, that pretty much sums it up.

Sean