Bill Cox wrote:
> Jonathan Andrew wrote:
> 
>> Sigh. I suppose we might as well take lemons and make lemonade out of the no
>> boolean situation. Should that be an alias or a typedef though?
>>
>> -Jon
>>
>> In article <3EFCA3B6.5010802@viasic.com>, Bill Cox says...
>>
>>> Hi.
>>>
>>> It's Friday, and I've just had my third beer, which makes me nastier than usual.
>>>
>>> In that spirit, re-reading the 'Boolean type' posts, I find I'm convinced that at least half of us will create little 'bool.d' files containing the single line:
>>>
>>> alias bit bool;
>>>
>>> If we can all agree that this is the standard definition, and that it lives in "bool.d", we can all write much more compatible code. Otherwise, I'll have to have something doppey like "mybool.d" containing the equally doppey "alias bit mybool;".
>>>
>>> Anyone with me?  Shall we make it a defacto standard?
>>>
>>> Bill
>>>
>>
>>
>>
> 
> Argh!  I don't care!  Byte is fine.  Typedef is fine.  I just want a 'bool' type so I can get mad when I see programmers adding bools and ints.  When I say bool, I mean bool.
> 
> Bill
> 
> P.S.  I'm into a bit of rum now, so please ignore me.
> 
It has to be an alias, or we won't be able to do assignments with 'true' and 'false' without casts.

It needs to go into Phobos.

Sean

"Bill Cox" <bill@viasic.com> wrote in message news:3EFCA3B6.5010802@viasic.com...
> Hi.
>
> It's Friday, and I've just had my third beer, which makes me nastier than usual.
>
> In that spirit, re-reading the 'Boolean type' posts, I find I'm convinced that at least half of us will create little 'bool.d' files containing the single line:
>
> alias bit bool;
>
> If we can all agree that this is the standard definition, and that it lives in "bool.d", we can all write much more compatible code. Otherwise, I'll have to have something doppey like "mybool.d" containing the equally doppey "alias bit mybool;".
>
> Anyone with me?  Shall we make it a defacto standard?
>
> Bill

You can specify the underlying type of an enum in D.  But I forget exactly how.  Does anyone remember?

Sean

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:bdicah$10so$1@digitaldaemon.com...
> It has to be an alias, or we won't be able to do assignments with 'true' and 'false' without casts.

Looking for this?

enum bool : bit
{
    	TRUE=false,
    	FALSE=true
}



Farmer.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in news:bdna96$pag$1@digitaldaemon.com:

> You can specify the underlying type of an enum in D.  But I forget exactly how.  Does anyone remember?
> 
> Sean
> 
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:bdicah$10so$1@digitaldaemon.com...
>> It has to be an alias, or we won't be able to do assignments with 'true' and 'false' without casts.
> 
> 

That looks like it.  Thanks!

Sean

"Farmer" <itsFarmer.@freenet.de> wrote in message news:Xns93AAEF916A3AAitsFarmer@63.105.9.61...
> Looking for this?
>
> enum bool : bit
> {
>     TRUE=false,
>     FALSE=true
> }
>
>
>
> Farmer.
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in news:bdna96$pag$1@digitaldaemon.com:
>
> > You can specify the underlying type of an enum in D.  But I forget
exactly
> > how.  Does anyone remember?
> >
> > Sean
> >
> > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:bdicah$10so$1@digitaldaemon.com...
> >> It has to be an alias, or we won't be able to do assignments with
'true'
> >> and 'false' without casts.

Same here

"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bdi8dp$sdq$1@digitaldaemon.com...
> In article <3EFCA3B6.5010802@viasic.com>, Bill Cox says...
> >
> >Hi.
> >
> >alias bit bool;
>
> Except mine would be
>
> alias byte bool;
>
>

typedef

"Jonathan Andrew" <jonNO@SPAMece.arizona.edu> wrote in message news:bdi93p$td6$1@digitaldaemon.com...
>
> Sigh. I suppose we might as well take lemons and make lemonade out of the
no
> boolean situation. Should that be an alias or a typedef though?
>
> -Jon
>
> In article <3EFCA3B6.5010802@viasic.com>, Bill Cox says...
> >
> >Hi.
> >
> >It's Friday, and I've just had my third beer, which makes me nastier than usual.
> >
> >In that spirit, re-reading the 'Boolean type' posts, I find I'm convinced that at least half of us will create little 'bool.d' files containing the single line:
> >
> >alias bit bool;
> >
> >If we can all agree that this is the standard definition, and that it lives in "bool.d", we can all write much more compatible code. Otherwise, I'll have to have something doppey like "mybool.d" containing the equally doppey "alias bit mybool;".
> >
> >Anyone with me?  Shall we make it a defacto standard?
> >
> >Bill
> >
>
>

Matthew Wilson wrote:
> typedef

no, alias. or just get used to thinking in bits, which i prefer. typedef would make lots of trouble.

-i.

Sorry, your explanation makes no sense. Can you expound?

btw, am now wondering whether int is better than byte. It's a trade off of efficiencies, whether storage (as in arrays/containers of bool) vs function returns and the painful/wasteful testing against 0 to convert to true/false.

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:bei0i5$6ur$1@digitaldaemon.com...
> Matthew Wilson wrote:
> > typedef
>
> no, alias. or just get used to thinking in bits, which i prefer. typedef would make lots of trouble.
>
> -i.
>

bool is one of those types (like int) that should be defined by its semantics and not by its implementation details.  You won't get any guarantees about how big a bool is.  It could be a bit, a byte, or an int. It could in fact not live in memory but in a processor flags register.  But it seems important to be able to have pointers to them, send them as inout parameters, etc.  To do that, the compiler may need to temporarily move the value somewhere that can be referenced easier (a byte in memory) and then move it back when the reference is no longer necessary.  Since you can pass addresses around willy-nilly in D, this can get a programmer in big trouble, and means the compiler is severely constrained in what it is allowed to do without breaking language semantics.

bit is more like int32; it is saying exactly the storage requirement for the value.  A cheap D compiler could use a byte to hold a bit if it wants to, though.  It also seems pretty important to be able to have pointers to bits. A bit pointer however is unlike a normal pointer in that it must specify which bit in the containing byte it is actually pointing to.  This would need special compiler support, and Walter doesn't seem interested in making this effort at this time.  Has many more important things that need doing, apparently.  ;)

One thing that could be done to alleviate the problem somewhat would be that local, class, and global scope variables have *no* defined ordering or size, and thus you can't determine the address of a variable merely by looking at the class declaration and knowing a pointer to the class,  you'd have to use offsetof(x).  With the language semantics so altered, it would be possible to take the address of a local variable bit or bool, which would let the compiler store it as a byte instead of a bit.  Taking the address of bits stored in structs or arrays could wait until Walter makes fat bit pointers.

Sean

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:beid7m$jh2$1@digitaldaemon.com...
> Sorry, your explanation makes no sense. Can you expound?
>
> btw, am now wondering whether int is better than byte. It's a trade off of efficiencies, whether storage (as in arrays/containers of bool) vs
function
> returns and the painful/wasteful testing against 0 to convert to
true/false.
>
> "Ilya Minkov" <midiclub@8ung.at> wrote in message news:bei0i5$6ur$1@digitaldaemon.com...
> > Matthew Wilson wrote:
> > > typedef
> >
> > no, alias. or just get used to thinking in bits, which i prefer. typedef would make lots of trouble.
> >
> > -i.