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?

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

I think you shouldn't remove it unless you are replacing it with a true (pardon the pun) boolean type. To me, bool doesn't have to be a completely distinct type from, say, int (it could even be an alias for int). But it should still be an available type.

On Thu, 16 Feb 2006 16:47:21 -0800, 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?

I regard a 'bit' as a part of a collection. Access to groups of one or more adjacent bits seems to be a normal system programming function and should not be hampered. What would be useful is to make easy syntax to access them rather than combinations of '&', '~', and '|'. So maybe the idea like bit structures that allow us to name bit collections and have D do the fancy stuff for us. A collection of bits could be regarded as tiny unsigned integers.

A boolean exhibits the follow characteristics:
** It has only ever two states. Let's call then true and false for now.
** It can not take part in arithmetic. The compiler must flag this as an
error.
** It can not take part in relative comparisons (ie. > < >= <=).  The
compiler must flag this as an error.
** It can take part in equality tests (==, !=)
** The ! operand returns the value which it is currently not.
** The binary operands ( ~ &  | ) are not permitted.
** The boolean operands ( ! && || ) are permitted
** It can be explicitly cast to an integer such that false is 0, and true
is 1.
** A numeric value can be explicitly cast to a boolean such that 0 is
false, and non-zero is true.
** It's formatted %s value is either "false" or "true"
** It's formatted %d value is either 0 or 1
** How this is implemented is not relevant from the coders POV, so if you
use an int or short or byte to represent a boolean's storage that's just
fine.
** boolean.size should return the number of bytes used to implement it.
** boolean.init should be false
** boolean.min should not be allowed
** boolean.max should not be allowed
** An array of booleans is permitted.
** Address of a boolean is permitted.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
17/02/2006 12:03:48 PM

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?

Please remove it.  Packed bit arrays are a good thing, but not as a language feature in this case.


Sean

John Stoneham wrote:
> 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?
>>
> 
> I think you shouldn't remove it unless you are replacing it with a true (pardon the pun) boolean type. To me, bool doesn't have to be a completely distinct type from, say, int (it could even be an alias for int). But it should still be an available type.

Good point.  If 'bit' is going away then we need some form of boolean type to replace it.  But I'll accept it being as loosely defined as bit is now--my primary concern is that its value must always be either 'true' or 'false'.


Sean

Derek Parnell wrote:
> On Thu, 16 Feb 2006 16:47:21 -0800, 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?
> 
> 
[snip]
> 
> A boolean exhibits the follow characteristics:
> ** It has only ever two states. Let's call then true and false for now.
> ** It can not take part in arithmetic. The compiler must flag this as an
> error.
> ** It can not take part in relative comparisons (ie. > < >= <=).  The
> compiler must flag this as an error.
> ** It can take part in equality tests (==, !=)
> ** The ! operand returns the value which it is currently not.
> ** The binary operands ( ~ &  | ) are not permitted.
> ** The boolean operands ( ! && || ) are permitted
> ** It can be explicitly cast to an integer such that false is 0, and true
> is 1.
> ** A numeric value can be explicitly cast to a boolean such that 0 is
> false, and non-zero is true.
> ** It's formatted %s value is either "false" or "true" ** It's formatted %d value is either 0 or 1
> ** How this is implemented is not relevant from the coders POV, so if you
> use an int or short or byte to represent a boolean's storage that's just
> fine.
> ** boolean.size should return the number of bytes used to implement it.
> ** boolean.init should be false
> ** boolean.min should not be allowed
> ** boolean.max should not be allowed
> ** An array of booleans is permitted.
> ** Address of a boolean is permitted.
> 

Well said!
This is what bools should before 1.0!

Bit could be aliased in the interim.


"Sean Kelly" <sean@f4.ca> wrote...
> John Stoneham wrote:
>> 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?
>>>
>>
>> I think you shouldn't remove it unless you are replacing it with a true (pardon the pun) boolean type. To me, bool doesn't have to be a completely distinct type from, say, int (it could even be an alias for int). But it should still be an available type.
>
> Good point.  If 'bit' is going away then we need some form of boolean type to replace it.  But I'll accept it being as loosely defined as bit is now--my primary concern is that its value must always be either 'true' or 'false'.
>
>
> Sean

"Walter Bright" <newshound@digitalmars.com> 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?


Yes; please do.

A library class or struct BitSet, perhaps with some jolly op-overloads (such as opIndex and friends), would do the job very nicely instead.

In article <dt36tu$1lg3$2@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?
>
>

I think a distinct boolean type of some kind should be availaible. In c++ I am
always having to add a special boolean version of overridden methods, for
example:
void set( short val );
void set( int val );
void set( long val );
->  void setBool( bool val ); <- set( bool ) would conflict with set( int )

which then adds compounded complexity with templates(macros) etc....

so personally i think bool should at least be a built in typedef

On Thu, 16 Feb 2006 16:47:21 -0800, Walter Bright <newshound@digitalmars.com> 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?

Yes, get rid of it.

I think we need a "bool" type that can only have 2 values: true and false.

I think we need some way to handle packed bits, a BitSet class/struct and/or a BitStream/BitBuffer class and library functions to hide the & | and ^ ickiness (there are some in std.intrinsic).

Regan