On 2006-02-16 20:28:20 -0800, Julio César Carrascal Urquijo   <jcesar@phreaker.net> said:

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

Well yeah, if you want to do that...  Are you trying to write messed up code?

-S.

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 guess I'm in the minority here but I have an affinity for bit and would be sad to see it go.  There is something strangely soothing about having a bit variable and knowing that there is actually a bit somewhere out there in the vast expanse of my computer's memory that is fulfilling its purpose in keeping track of a single bit.  It is in some way, beautiful.

I'm the guy who always had classes in C++ to encapsulate just the number of bits that I wanted in that ever-bizarre now-forgotten syntax.

[/EmotionalAppeal]

Mark D.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dt36tu$1lg3$2@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.
>
> 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 only ever use bit for boolean values anyway, so I wouldn't miss it. Besides, the "compiler support" for bit[] has never really extended beyond packing the bits automatically into a word.  Were it possible to cast integral types to bit[] and back, it would be a little more useful, but that could be done just as easily and just about as nice-looking with library support.

The one thing I like about bit, though, is that it's really quick to type ;)

[snip]
> 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'm getting this feeling too ..
The main overview page http://digitalmars.com/d/overview.html says:

>C++ programmers tend to program in particular islands of the language,
>i.e. getting very proficient using certain features while avoiding
>other feature sets. While the code is usually portable from compiler to
>compiler, it can be hard to port it from programmer to programmer. A
>great strength of C++ is that it can support many radically different
>styles of programming - but in long term use, the overlapping and
>contradictory styles are a hindrance.

This is true for D too, now.

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.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
17/02/2006 4:54:16 PM

On Thu, 16 Feb 2006 23:28:20 -0500, Julio César Carrascal Urquijo wrote:

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

And you can do arithmetic with enums...

enum Bool
{
     True = 1,
     False = 0
}

void main()
{
	Bool b1 = Bool.False;
	Bool b2 = Bool.True;
	int  b3 = b1 * 3 + (b2 - 7) / (b1 + Bool.True);
}

But you should not be able to do that with booleans.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
17/02/2006 5:00:21 PM

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


Although I agree that bit[] and bit* have been a failure, bit by itself is pretty nice in my view.

Say my largely complex class has 200 bit variables. The compiler packs that into 25 bytes, nice! But now what, we alias it to byte and it becomes 200 bytes.. not so good.. or alias to int and it becomes 800! not good at all.

I think bit by itself has its benefits. You may be thinking that keeping bit and removing bit* and bit[] is inconsistent. Well, bits ARE inconsistent, you can't even directly address them, so why should we pretend that bit is consistent.

Should I change my 200 bit variables to int and use bit flags and masks? I would in C, but this bit is so much nicer.

You could tell me that the new replacement bool type would be smart enough to pack them into bits. How well has that been for C++? I don't actually know, but it seems to me that this is difficult to do effectively because even if you are _able_ (not even directly) to get the address of a bool, it has to put it in at least a byte, but I could be wrong. Plus to do this, code would have to be inserted to pack it correctly, i.e. a simple assignment does magic. Sure the current bit variable has to do this, but it is known and expected. Doesn't it make the new bool look inconsistent?

One last thing, bit could still be useful in place of C bit fields and still not need pointer-to-bit:
struct foo
{
   union
   {
      struct { bit b0; bit b1; bit b2; bit b3; bit b4; bit b5; bit b6; bit b7; }
      byte by;
   }
}


Now about a new bool type. Yes, add one. What should the size be? byte or int; byte has size benefits, int has efficiency benefits. It would probably be best to go with int (actually, ptrdiff_t). Should it be possible that the value be other than true/false? why not! (not asking for a flame war) Just like the current opEquals returns int for efficiency, you can easily convert a value you have at your disposal to a bool (e.g. an int, pointer, HANDLE, etc) without any wasted cycles. But, when comparing with other values, it should only act like true/false. i.e. mybool==true should not be like mybool==1, it should be like mybool!=false, so you see it as having true/false even though it may be any variation of true.

Here's my thought on implicit conversions to/from new bool:
   NO:  int -> bool           - requires cast, no cycles wasted.
   NO:  pointer -> bool       - same as above.
   YES: bool -> int/byte/long - why not? Allows easy integration with C int as boolean, for one.
   YES: bool -> bit           - why not? They have the same true/false meaning. Also backwards compatible with current bit/bool.
   NO:  bool -> char/etc      - no relation, requires cast.


Thanks for your time;
- Chris

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dt36tu$1lg3$2@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.
>
> 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?

Strongly agree.

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

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.

(btw, I'd hardly look upon the situation with recls any kind of victory, for
anyone. But if you mean it's good to have _some_ resolution then I agree
with
that.)

Good to hear bit's going though. I strongly support that, and the introduction of a bool(ean) replacement that is not implicitly convertible to an integral type. (But I'm not getting involved in a fracas on that point ... <g>)

Matthew

Chris Miller wrote:

> On Thu, 16 Feb 2006 19:47:21 -0500, 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?
> 
> 
> Although I agree that bit[] and bit* have been a failure, bit by itself is pretty nice in my view.
> 
> Say my largely complex class has 200 bit variables. The compiler packs that into 25 bytes, nice! But now what, we alias it to byte and it becomes 200 bytes.. not so good.. or alias to int and it becomes 800! not good at all.

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);

> Should I change my 200 bit variables to int and use bit flags and masks? I would in C, but this bit is so much nicer.

A couple of months ago I implemented simple BitArray StaticBitArray and BitField templates just to get a feeling for how a library replacement for bit[] could work. http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.announce/2212 (Searching the newsgroup would turn up other's implementations aswell) The only semantic difference to built in bits is:

- StaticBitArray!(n) would become a value type and not a reference type like
bit[n] is. (bit[n] behaves like a value type on declaration (allocates
storage on the stack/in the struct) but has reference semantics)

The advantages over builtin bit arrays are:
- foreach with out and inout value.
- unaligned slices

Just for fun - the BitField hack:

typedef void ready, write_protected, loaded, error_code, command;
BitField!(
  ready, 1,
  write_protected, 1,
  loaded, 1,
  error_code, 8,
  command, 5
) status;

assert(status.sizeof == 2);

status.ref!(error_code).opAssign(137);
status.ref!(command).opAssign(3);
status.ref!(ready).opAssign(1);

BitArray something = status.ref!(error_code) ~ status.ref!(command);

Attaching the code. (Incomplete, ugly and hackish, but working as a demo)

/Oskar