Okay I'm interresting in getting more infomation about the bit[] type;
- is it still implemented in D1? - and why was it removed?
- is it possible to get a link to the design considerations of removing it,
and such?
- any source of info, on the design phase about it, will be in my interrest

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Emil Madsen:

> Okay I'm interresting in getting more infomation about the bit[] type;
> - is it still implemented in D1? - and why was it removed?
> - is it possible to get a link to the design considerations of removing it,
> and such?
> - any source of info, on the design phase about it, will be in my interrest

D.learn is a better place to ask such questions.
In D1 now the bit type exists just as an alias.
I think it was removed because you can't get the address of a bit. D1 Phobos has functions in std.intrinsic to manage bit arrays, and D2 Phobos has a module that implements a bit array and a way to build struct bit fields.

Bye,
bearophile

Didn't knew about D.learn :) - I'll head over there, to ask questions alike
this one, instead of polluting here.
the bit type in D1, is just an alias for bool I take it, for backwards
compatibility`? - is it deprecated?

Yet again, thanks you :)

On 23 September 2010 00:32, bearophile <bearophileHUGS@lycos.com> wrote:

> Emil Madsen:
>
> > Okay I'm interresting in getting more infomation about the bit[] type;
> > - is it still implemented in D1? - and why was it removed?
> > - is it possible to get a link to the design considerations of removing
> it,
> > and such?
> > - any source of info, on the design phase about it, will be in my
> interrest
>
> D.learn is a better place to ask such questions.
> In D1 now the bit type exists just as an alias.
> I think it was removed because you can't get the address of a bit. D1
> Phobos has functions in std.intrinsic to manage bit arrays, and D2 Phobos
> has a module that implements a bit array and a way to build struct bit
> fields.
>
> Bye,
> bearophile
>


-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Emil Madsen:

> the bit type in D1, is just an alias for bool I take it, for backwards compatibility`?

I think so. But it's only a partial semantic compatibility.


>- is it deprecated?

bit as alias of bool is not deprecated, because I presume this alias will never be removed from D1, but there's no need to use it in new D1 code.
And in a sense the whole D1 language is deprecated :-)

Bye,
bearophile

On 22/09/2010 22:26, Emil Madsen wrote:
> Okay I'm interresting in getting more infomation about the bit[] type;
> - is it still implemented in D1?

bit is now just an alias of bool, defined in object.

> - and why was it removed?

I think because there were too many complaints of bugs with it, and the conclusion was reached that it's too difficult to implement without bugs.

> - is it possible to get a link to the design considerations of removing
> it, and such?
<snip>

There must have been a discussion that led to it, but I can't find it at the moment.

Stewart.

== Quote from Stewart Gordon (smjg_1998@yahoo.com)'s article
> On 22/09/2010 22:26, Emil Madsen wrote:
> > Okay I'm interresting in getting more infomation about the bit[] type; - is it still implemented in D1?
> bit is now just an alias of bool, defined in object.
> > - and why was it removed?
> I think because there were too many complaints of bugs with it, and the conclusion was reached that it's too difficult to implement without bugs.
> > - is it possible to get a link to the design considerations of removing it, and such?
> <snip>
> There must have been a discussion that led to it, but I can't find it at
> the moment.
> Stewart.

I don't remember the details, but from the changelog
(http://www.digitalmars.com/d/1.0/changelog2.html), it looks like
Version D 0.148 (Feb 25, 2006) was when the last big change happened:
 * Removed bit basic type.
 * Added bool basic type.
 * Added BitArray.

These page covers some of the early controversy: http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit/PostsByWalter

I don't think the pages has been updated with much (if any) detail about how and why the change finally happened removing "bit", but it does looks like the "bool" alias was added in D 0.69 (August 11, 2003).

As you can see from the links to newsgroup threads at the bottom of the first page, the topic was discussed over many years. Perhaps the discussions have tapered off in recent years because the current approach is right.

jcc7

jcc7 wrote:
> As you can see from the links to newsgroup threads at the bottom of the first
> page, the topic was discussed over many years. Perhaps the discussions have
> tapered off in recent years because the current approach is right.

BTW, C++ ran into the same problems with vector<bool>.

jcc7:

> As you can see from the links to newsgroup threads at the bottom of the first page, the topic was discussed over many years. Perhaps the discussions have tapered off in recent years because the current approach is right.

It's an interesting read, thank you (I was present only at the tail of it).

It's a good example of how even an "obviously simple" feature like a bool/bit type may hide complexities, design difficulties, requires engineering trade-offs, and in the end may produce something with some inevitable design defects.

~bool is forbidden, but in DMD a bool is represented with 8 bits, so it has 255 ways to be true and 1 to be false. A boolean like this:

bool b = void;

May contain something different from 0 or 1, this may cause some surprise.

In those discussions I have seen Walter against the usage of bool as return type for opEquals, because a cast(bool)some_int is equivalent to:
n ? 1 : 0
That requires some instructions, so it isn't fully efficient.

In the pages (operatoroverloading.html and hash-map.html) about the D2 language I have seen different signatures for the struct opEquals, so I may add a little documentation bug report about it:
int opEquals(ref const S s);
const bool opEquals(ref const KeyType s);

P. 258 of TDPL shows a struct opEquals that returns a bool, so I presume the efficiency considerations have left space for a more semantically clean implementation. Isn't DMD able to optimize away (when inlining is present) the slowdown caused by the n?1:0 ?

Bye,
bearophile