In article <ck5ccl$tit$1@digitaldaemon.com>, Arcane Jill says... I seem to be alone in that opinion, ....

No, you are not alone, and this issue is not going to go away.  These are colossal blunders.

It is so hard for programmers to catch these errors, and so trivial for compilers, that it is very poor language design to require the programmer to check data types.

Rex Couture wrote:

> No, you are not alone, and this issue is not going to go away.
> These are colossal blunders.

I don't agree. They are *deliberate* decisions, to make the language
more "compatible" with C and C++. We just differ a little - in which
parts of the old languages to keep around, and which parts to change...

I too find it strange to keep the old arithmetic logic, since it
also says to "drop C source code compatibility". But it's done.
And since the decision has been made, better leave it for D++ ?

> It is so hard for programmers to catch these errors, and so trivial for
> compilers, that it is very poor language design to require the programmer to
> check data types.

I may disagree with Walter's decision on booleans/characters/strings,
but still like the overall design of D. It does warn about some bugs,
like when you use a non-boolean result such as the common: if (a = b)

And if you really *hate* both C and C++, then maybe D is not the one ?

--anders

PS. There sure are a *lot* of posts about this topic in this newsgroup!
    I missed some because of odd subjects like "compiler compatibility"

In article <ck6os7$24an$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>They are *deliberate* decisions, to make the language
>more "compatible" with C and C++.

That's what they said about C++ too.  What's so great about complete compatibility?  Recompilation with stricter rules is almost certain to uncover lots of errors.


>I may disagree with Walter's decision on booleans/characters/strings,....

Ah, so you do disagree.  :-)  I think it's a great language too -- with this one huge wart.

J C Calvarese wrote:
> Ben Hinkle wrote:
> 
>> Arcane Jill wrote:
>>...
> It's really a religious discussion.
> 
> Some people believe in Bool.
> Others believe in Bit.
> 
> Some people are Reformed Boolists.
> Others are Eastern Orthodox Bitians.
> 
> Some people attend the Latter-day Church of Bool.
> Others are Bit's Witnesses.
> 
> Some people use false and true.
> Others use yin and yang.
> 
> I don't think Walter has written much other than he likes the way it ...
> I guess I'm an Agnostic with respect to bit/bool. I just use bit, and call it good.
> 
I, too, use bit, and consider it a reasonable bool.  But personally I expect that eventually I'll write a new class based around byte which will express around 212 degrees of certainty (and a few kinds of error conditions).  It expressly WON'T include TRUE! and FALSE!.  The logic that it uses will always imply that there's some element of uncertainty in each step (though probably less than 1 part in 424 when near the center of the range...toward the edges it will become more difficult to become more certain.  (I'd say asymptotically more difficult, but that doesn't really apply to a datatype that can be contained in a byte.  Still, it captures the idea.)  You could say that true would be 213 and false would be -1, but neither one would actually be a member of the class.

For now, I'm quite pleased to use bit, and think of it as bool. (But I would like it if the bit[n] type were retained as a packed array.)

i don't understand the bool/bit wars.
bit allows me to use true and false, just like bool does.
what am i missing? what is so dangerous about bit's true and false?

Anders F Björklund wrote:
> Is it too late to hope for D to get a *real* boolean type ?
> 
> That is, not the integer-compatible bit one that is "bool";
> but a special-purpose "boolean" type, like the one Java has.
> (accidently also present in C#, there under a name of bool)
> 
> 
> I was hoping for the following code snippets to be illegal:
> 
> if (pointer)
> if (a = b) // just a typo!
> if (c = readchar())
> i = true + 1;
> 
> Instead they could be replaced by the equivalent new code:
> 
> if (pointer != null)
> if (a == b) // what was meant!
> if ((c = readchar()) != 0)
> i = (true ? 1 : 0) + 1;
> 
> The first block is C/C++, and the second block is Java/C#.
> 
> 
> It seems like "true" and "false" has already been defined
> as "bit", which I think is unfortunate. They should have
> been "boolean". Better bit names would be "on" and "off".
> 
> Can it be added/changed, or are we stuck with C9X/C++ bool?
> 
> --anders
> 
> 
> PS.
> Aliasing "bit" to represent "bool" is perfectly fair.
> It's even *better* than what my current GCC 3.4 does,
> where sizeof(bool) == 4 ! (I'm guessing it uses "int")
> 
> Just that I had hoped for something that was better...
> (since C source code compatibility is not an issue ?)
> Or did Walter actively CHOOSE the old C style, for D ?

clayasaurus wrote:

> i don't understand the bool/bit wars.

The wars are over... The bad guys won ;-)

C/C++ on one side, Java/C# on the other.

> bit allows me to use true and false, just like bool does.

No, bit allows you to use 1 and 0. There's a difference.

That said; "bool", "true" and "false" are valid keywords.
They work more or less the same in all of C9X, C++ and D.

> what am i missing? what is so dangerous about bit's true and false?

It's not type-safe. Some people think that's a bad thing.

--anders

Anders F Björklund wrote:
>
>> what am i missing? what is so dangerous about bit's true and false?
> 
> It's not type-safe. Some people think that's a bad thing.

And bit vectors don't behave quite like vectors of anything else, because the bit values are compressed.  This has potential issues for template programming (though C++ faces a similar problem with vector<bool>).


Sean

"Anders F Björklund" <afb@algonet.se> wrote in message news:ck1joc$4bl$1@digitaldaemon.com...
> I just wanted to point out that C(9X) and C++ chose one solution,
> and that Java and C# chose another ? D currently sides with the
> C side, just wanted to know if that was by choice or by accident ?

It's by choice. (Though many disagree with that choice.)

"Anders F Björklund" <afb@algonet.se> wrote in message news:ck85pc$5gl$1@digitaldaemon.com...
> > bit allows me to use true and false, just like bool does.
> No, bit allows you to use 1 and 0. There's a difference.

I've been around long enough to have actually constructed computer hardware out of ttl logic gates. There, 'true' and 'false' are voltage levels. Low voltage, high voltage, false, true, off, on, 0, 1, all the same.

The D 'bit' type is a true boolean - it can only contain two values.

Walter wrote:

>>>bit allows me to use true and false, just like bool does.
>>No, bit allows you to use 1 and 0. There's a difference.
> 
> I've been around long enough to have actually constructed computer hardware
> out of ttl logic gates. There, 'true' and 'false' are voltage levels. Low
> voltage, high voltage, false, true, off, on, 0, 1, all the same.

Hehe, and I sometimes think that *I* am old in this game...

bool vs. boolean and 1 vs. true only makes a difference
if the logic and conditionals is not arithmetic. Otherwise
it's the same, although some find true/false more readable.

Maybe I should start using a "Yao" type with Yin/Yang values ? ;-)

> The D 'bit' type is a true boolean - it can only contain two values.

Yes, that integer type sounds like a better choice for "bool"
than the usual choices of char or int... But I'll just use bool.

And I'll keep saying that bit contains 0/1, and bool false/true ?
Not that it makes any difference in D, just makes me feel better...

Case Closed.
--anders


PS. Thanks for adding the aliases bool/true/false to the language!
    This means I can just don my old C99 / C++ hat, and it'll work.