"Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:dt3utv$27h2$1@digitaldaemon.com...
> A _highly_ doubtful proposition.  I think Walter makes up his mind pretty
> much
> on technical merits alone. I suspect he's just reaching a level of
> momentum
> with the
> language as he perceives it and is simply clearing up (popular)
> outstanding
> issues.

I attended the NWCUG meeting yesterday, and got into a long discussion about D (NWCUG gets some top people to attend, so I can get some pretty good feedback). The discussion turned towards mistaken language ideas and any screwups in D, and of course I thought of bit. The others suggested why not remove bit? I had thought we were stuck with it for backwards compatibility reasons, but then I thought I'd pose the question here.

There's also the issue brought up here that perhaps D is accreting too many kludgy features. Bit is certainly a kludgy feature with too many special cases, and so things would definitely get simpler without it.

I definitely get the feeling that D is gaining momentum. Everywhere I go now, people have heard of D. They may not be writing programs in it yet, but they're aware of it and a lot of influential people are keeping tabs on its progress. I've been invited to give yet another presentation on D at a major company tomorrow.

On Fri, 17 Feb 2006 04:09:42 -0500, Oskar Linde <olREM@OVEnada.kth.se> wrote:

> The compiler can not pack those 200 bit variables as long as anything may
> want to take their addresses.
>
> struct Test {
>         bit a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;
> }
>
> ...
>
> assert(Test.sizeof==26);


I'm not sure that's the reason, it could be due to struct alignment. Do the same with a class (using classinfo.init.sizeof) and it appears packed. If something like align(0) were allowed, they could pack in a struct.

Chris Miller wrote:

> On Fri, 17 Feb 2006 04:09:42 -0500, Oskar Linde <olREM@OVEnada.kth.se> wrote:
> 
>> The compiler can not pack those 200 bit variables as long as anything may want to take their addresses.
>>
>> struct Test {
>>         bit a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;
>> }
>>
>> ...
>>
>> assert(Test.sizeof==26);
> 
> 
> I'm not sure that's the reason, it could be due to struct alignment. Do the same with a class (using classinfo.init.sizeof) and it appears packed.

Try classinfo.init.length instead.

/Oskar

Derek Parnell wrote:
> On Thu, 16 Feb 2006 20:05:58 -0800, S. Chancellor 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 <g>.
> 
> This is only a small partial solution and one that brings other
> problems as well. Try it out to see what I mean. In essence though,
> its still an integer and not a boolean.

Anybody ever thought of _why_ we have both & and && ?

Thinking that through will make most of this entire thread redundant.

On Fri, 17 Feb 2006 04:14:37 -0500, Oskar Linde <olREM@OVEnada.kth.se> wrote:

> Chris Miller wrote:
>
>> On Fri, 17 Feb 2006 04:09:42 -0500, Oskar Linde <olREM@OVEnada.kth.se>
>> wrote:
>>
>>> The compiler can not pack those 200 bit variables as long as anything may
>>> want to take their addresses.
>>>
>>> struct Test {
>>>         bit a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;
>>> }
>>>
>>> ...
>>>
>>> assert(Test.sizeof==26);
>>
>>
>> I'm not sure that's the reason, it could be due to struct alignment. Do
>> the same with a class (using classinfo.init.sizeof) and it appears packed.
>
> Try classinfo.init.length instead.
>
> /Oskar
>

Oops! well, if bit variables were never intended to be packed, then I'm all for removing bit.

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?

Yes! But I have one question: what will happen to bool, will it now be an alias to int? Will we get a real bool type? (Will if and while still expect int or will they expect bool?)

> 
> There is a place for bit[] as a library type, though.

That is where it belongs since it is hard to implement in the language keeping it consistent with other array types.

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

A bit type is a bit weird, but as long as there'll be a library replacement available, I agree with the removal, though it doesn't matter what I agree or not.

*nods*

Regards,
Alex

Derek Parnell wrote:
> 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.
> 

As long as we get a boolean along these lines - of size 1 bit, 8 bits, 32 bits, 64 bits, whatever -, I don't really care what happens to bit/bit[].

I haven't yet used bit[] at all, except in a few cases where I thought I could use it as a "normal" array of booleans. Of course, that doesn't count, since the code didn't behave as I expected.

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, axe it.
And we should take this opportunity to make a better bool. I make mine's Derek's comments about bool.

And please, *please*, do not keep yourself from doing good changes to the languages because of backwards compatibility, especially if the language is still in development. We should try to get the best D as possible out there, and it's not good if we start getting hampered already with the same design impediments that plague C/C++ such as backwards compatibility. Not that we should be changing D all the time, but keep this in mind.


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

I don't use it.

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