On Fri, 17 Feb 2006 16:05:52 +1300, Regan Heath <regan@netwin.co.nz> wrote:
> 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.

This type can be implemented however appropriate, for example it has been suggested that an int sized variable performs the best. Regardless, as long as the type can only have 2 values it will do the job I reckon.

Regan

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?

Yes, please remove!

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

Hear Hear!

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?

Stone dead.

>There is a place for bit[] as a library type, though.
>
>So what do people think?

Firing squad immediately. No mercy

In article <14shfnb64x5o2.17cec6fac7wnu.dlg@40tude.net>, Derek Parnell says...
>
>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.

Perfectly defined!
A quote in spanish: "Más claro, echarle agua".
In english it'd be something like "To get it clearer, pour water on it".
Amen.

You have my vote to remove 'bit' and replace it with 'bool'.

P.S.: Lately I've been having the feeling that D is getting TOO overloaded. The last threads made me feel a little dizzy. Maybe it's time to add only the most relevant lacking features (and remove/replace the most unwanted, unpopular and irrelevant ones) and complete/improve the infrastructure to make D a true competitor.

Tom;

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

Maybe there is intent to Matthews' rsants and raves? Hes had some strong attacks on Walter in last month, and now like manna from heavan 3-4 long, long bugbears in D are being handled in some way or considered by The Man: bit, warnings, recls, $ & regexp.

Is he golden prince still with the kings ear? Even if he is now exiled black prince he seems to serve e useful putpose. Shout again, naughty boy!

You're not fooling anyone, Matthew.


"One Wise Monkee" <One_member@pathlink.com> wrote in message news:dt3h6b$1t7e$1@digitaldaemon.com...
> >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.
>
> Maybe there is intent to Matthews' rsants and raves? Hes had some strong
> attacks
> on Walter in last month, and now like manna from heavan 3-4 long, long
> bugbears
> in D are being handled in some way or considered by The Man: bit,
> warnings,
> recls, $ & regexp.
>
> Is he golden prince still with the kings ear? Even if he is now exiled
> black
> prince he seems to serve e useful putpose. Shout again, naughty boy!
>
>
> 

On 2006-02-16 18:43:32 -0800, "Kris" <fu@bar.com> said:

> Bit could be aliased in the interim.

Why can't it be an enumerated type?

enum bool {
	true = 1,
	false = 0
}

From the documentation:

Named enum members can be implicitly cast to integral types, but integral types cannot be implicitly cast to an enum type.
Seems like this is the functionality we're looking for?  Or am I confused?

-S.

"S. Chancellor" <dnewsgr@mephit.kicks-ass.org> wrote
> On 2006-02-16 18:43:32 -0800, "Kris" <fu@bar.com> said:
>
>> Bit could be aliased in the interim.
>
> Why can't it be an enumerated type?
>
> enum bool {
> true = 1,
> false = 0
> }
>
> From the documentation:
>
> Named enum members can be implicitly cast to integral types, but integral
> types cannot be implicitly cast to an enum type.
> Seems like this is the functionality we're looking for?  Or am I confused?

Yes, that's the gist of it ~ for those folks who currently use bit as a type (rather than bool), then bit could be aliased to whatever replaces it. Perhaps to the enum you illustrated above. This branch of the topic started, I think, with a concern from Thomas regarding the removal of bit[] whilst leaving bit. I think we were just trying to show how both can be removed without causing lots of grief for existing code.

S. Chancellor wrote:
> Why can't it be an enumerated type?
> 
> enum bool {
>     true = 1,
>     false = 0
> }

Because an integer can be converted to a enumerated type easily:

enum Bool
{
    True = 1,
    False = 0
}

void main()
{
	Bool b1 = Bool.False;
	Bool b2 = Bool.True;
	Bool b3 = cast(Bool)3;	// No cast exception thrown.
}