Get rid of bit and bit[] ?

Kevin Bealer Kevin_member at pathlink.com
Wed Feb 22 20:45:10 PST 2006


In article <dt36tu$1lg3$2 at digitaldaemon.com>, Walter Bright says...
>
>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? 

If it's that complex to implement bit[], a library seems fine to me.

But if you're tossing "bit" for being ugly, it should be to replace it with
something cleaner, with equal or better performance.  Is there a replacement for
bit that works as well and doesn't require implicit (x ? 1 : 0) branches
inserted everywhere?

I think the worst thing would be to have a language designed by the influence of
the people who complained.  I think Java got rid of unsigned types for this
reason.  Every CPU you can buy supports unsigned, but Java can't.

*All* low level programming has to deal with ugly, machine oriented realities.
This will always bother some people.

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?"

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?

Kevin





More information about the Digitalmars-d mailing list