"Walter" <walter@digitalmars.com> wrote in message news:bgpbmc$29go$1@digitaldaemon.com...
> 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.

Please.  You should know better than anyone that a compiler is far more suited to that task than any person.  It's tedious, error-prone grunt work, and nobody should have to do that anymore.  It's 2003, not 1970.  ;) Besides, explicit bit masking is *UGLY*, and deserves to be hidden behind the scenes.

Sean

Walter wrote:
> "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);

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.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bh0c75$2ppg$1@digitaldaemon.com...
> Walter wrote:
> > "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);
>
> 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.

I'm with you, my bold bool brother

In article <bgtu7o$hu1$1@digitaldaemon.com>, Mike Wynn says...
>
>>
>> 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).

I agree with this and many others do also  (why does Walter fight this??)

It may be Walter's language now but hopefully in the future it will be more than that, I don't think of Stroustrap as "owning" C++

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bh0c75$2ppg$1@digitaldaemon.com...
> Walter wrote:
> > "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);
> 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.

I disagree with the assessment that it's a lot of casting and support code. There's only one case, shown above, needing it. I don't think that justifies adding another basic type.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bgvm9a$25g6$1@digitaldaemon.com...
> 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.

It's implemented in 0.69.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bgvmgb$25ko$1@digitaldaemon.com...
> D is derived from C, not Pascal, and it should stick closer to C
conventions
> unless there are good reasons to stray.

Yes, exactly.

"Walter" <walter@digitalmars.com> wrote in message news:bh4nql$qhm$3@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bgvmgb$25ko$1@digitaldaemon.com...
> > D is derived from C, not Pascal, and it should stick closer to C
> conventions
> > unless there are good reasons to stray.
>
> Yes, exactly.
>
well then bit ain't bool and bool aint bit !!
to stick close to C bool is stored in int (where int is the most efficient
memory operand size no shorter than a short and no longer than a long) which
means short on 68k (16 bit bus), int on x86 and I guess short or int on Arm
depending on the machine etc and so on)
and its not a bit it can only have the values 0 (false) and 1 (true).
the result from (a < b) is a bool (in an int) not in a bit.

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:bgsml6$2cu1$1@digitaldaemon.com...
>
> 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.

If bits are not going to be usable as out parameters, then we definitely need
 separate bool (which can be used as out parameter), otherwise I can live with
 bool as language defined typedef for bit. Bit size should be really one bit
 and bit arrays should be "packed" (ie an array with 8 items should be only
 1 byte long); I think this is true now.
Bool size does *not* need to be the same as int at all, when it is not defined
 as extern(C). C++ uses one byte for bools and it is definitely different from int.

"Peter Hercek" <vvp@no.post.spam.sk> wrote in message news:bh6o62$2kru$1@digitaldaemon.com...
>
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message
news:bgsml6$2cu1$1@digitaldaemon.com...
> >
> > 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.
>
> If bits are not going to be usable as out parameters, then we definitely
need
>  separate bool (which can be used as out parameter), otherwise I can live
with
>  bool as language defined typedef for bit. Bit size should be really one
bit
>  and bit arrays should be "packed" (ie an array with 8 items should be
only
>  1 byte long); I think this is true now.
> Bool size does *not* need to be the same as int at all, when it is not
defined
>  as extern(C). C++ uses one byte for bools and it is definitely different
from int.

exactly C++ uses ...... C however uses "int" (and that's a C "int" NOT a D
int)
and D only has C linkage not C++