Get rid of bit and bit[] ?

[pragma]

In article <dtmh75$nn1$1 at digitaldaemon.com>, Don Clugston says...
>
>Walter Bright wrote:
>> I think the basic type bit has been a failure. It's a substantial increase 
>> in the compiler and runtime complexity to support it. Nobody seems happy 
>> about bit being a boolean type. There's no reasonable way to take a pointer 
>> to a bit, meaning that out and inout bit parameters are inconsistent and 
>> kludgy.
>> 
>> Should bit and bit[] be removed before 1.0?
>> 
>> There is a place for bit[] as a library type, though.
>> 
>> So what do people think? 
>
>Something I didn't see anyone mention is the fact that 'bit' isn't 
>really a native CPU type. x86 doesn't have any instructions that operate 
>on bits per se, except for the carry flag. Everything else is operations 
>on bits within integers. Bits are like quarks: everything is made out of 
>them, but you can never see one on its own.
>I think D has been pretending that there's such a thing as an isolated 
>bit, the same mistake that C++ made with vector<bool>. It's an illusion 
>that's too costly to maintain.

Good point.

I'd even go as far to say that even for embedded micro-controllers (like
Microchip PICs for example), I/O pins are managed as groups of 4, 8 or 16 to a
'port' at the assembler code level. So the bit[] paradigm wouldn't be a big gain
for that paradigm even though you wind up manipulating individual bits a fair
amount.

The only thing that bit[] had going for it was the potential for iteration via
foreach().  Since most uses of bit[] would map well to a single uint or ulong,
you can cover the bases with good old-fashioned flags, at the cost of some minor
syntax and value changes (powers-of-two versus bit indexing).

- Eric Anderton