Get rid of bit and bit[] ?

[Kevin Bealer]

In article <dtlvp3$2isk$1 at digitaldaemon.com>, Sean Kelly says...
>
>Kevin Bealer wrote:
>> 
>> But I think 80% of user complaints are driven not by real design motivations,
>> but by the "surprise" principle:  "Why doesn't it work the way I guessed it
>> would?"
>
>There's something to be said for predictability.  It doesn't have to be 
>a slippery slope :-)

I've thought about this more, and I mostly agree... But there are several
reasons for such predictions.  These come to mind:

A. My other language does X.
B. Java, C or C++ does X (special case, as these are sort of 'siblings' to D,
at least in the mind of users.
C. Mathematicians do X.
D. D does X in this other part over here.
E. WWDEKD? What would Donald E. Knuth do? :)
F. I just expected it out of the blue - I've never programmed before.
G. I just expected it out of the blue - I worked in assembler for years.

(A) and (C) are not important to me.  The (D) variant is the most important to
me.  (F) is semi-important but is the "web page" level of design, not great for
systems languages.  (G) is relevant for performance and hardware interfacing
cases especially.

(B) is relevant, but most of what we argue varies between Java, C, and C++, so
what we see is often (B) vs. (B), argued from different sides.

(E) is a religious question, as always... ;)

Kevin

>> This principle makes perfect sense at the high level (web page) but not at the
>> hardware level.  Software can be beautiful, but not "too beautiful for this
>> world".  If D gets the low level stuff right, it *has* to have ugly parts that
>> are fast a la C rather than pretty parts that are slow al la Java, in at least a
>> few, unremovable cases.
>> 
>> Is "bit" or "bool" one of these?
>
>I don't think so.  I find that the inability to address array-stored 
>bits causes me more trouble than is worth the benefits.  Particularly 
>considering that an equivalent library class could be created which 
>provides similar performance characteristics.
>
>
>Sean