www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Too late for boolean ?

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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 ?
Oct 06 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Anders F Bj=F6rklund schrieb:
 Is it too late to hope for D to get a *real* boolean type ?

 I was hoping for the following code snippets to be illegal:
=20
 if (pointer)

Why should that be illegal? I find it very elegant at many cases. Many=20 others also do.
 if (a =3D b) // just a typo!

Assignment in if statement is made illegal and will be rejected by the=20 compiler.
 Instead they could be replaced by the equivalent new code:

 i =3D (true ? 1 : 0) + 1;

I don't see a reason why this here should be done.
 Can it be added/changed, or are we stuck with C9X/C++ bool?

In principle, it is not like anything couldn't be changed by a technical = reason, we're not past 1.0 yet. However, such questions have already=20 been discussed dozens, dozens of times with no consensus. Your message=20 doesn't contribute much to the discussion because it fails to provide=20 any argument as to why we should do that. The common typo you show is=20 detected by the compiler. You didn't even check the code you post. -eye
Oct 06 2004
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ilya Minkov wrote:

 Why should that be illegal? I find it very elegant at many cases. Many 
 others also do.

Because the type of variable "pointer" is not a boolean ? This was after adding a new boolean core type to the language, and then requiring that if(), while() etc. get boolean params.
 if (a = b) // just a typo!

Assignment in if statement is made illegal and will be rejected by the compiler.

Great! (gcc catches it too, at least it issues a warning with -Wall: "warning: suggest parentheses around assignment used as truth value")
 i = (true ? 1 : 0) + 1;

I don't see a reason why this here should be done.

Again, because "boolean" and "int" are different types ? (pros and cons have been discussed before, won't reiterate)
 i = true + 1;


In C9X and C++, they both assign a value 2 to the i variable. In Java and C#, they both issue a fatal compiler "type error".
 In principle, it is not like anything couldn't be changed by a technical 
 reason, we're not past 1.0 yet. However, such questions have already 
 been discussed dozens, dozens of times with no consensus. Your message 
 doesn't contribute much to the discussion because it fails to provide 
 any argument as to why we should do that. The common typo you show is 
 detected by the compiler. You didn't even check the code you post.

I compiled the code now, and it did say: '=' does not give a boolean result 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 ? If there are no plans to add such a non-arithmetic type to D, then I'm perfectly fine with the current ones: bit, 1 and 0 - and their aliases: bool, true and false. I'm an old C user too. I just thought that like strings and garbage collection, "boolean" was a nice addition to C by Java, and hoped it would end up in D too... But if C and C++ have gotten along without it, so could D, I guess ? Just didn't see any strong statements that D would not ever add one... Sorry for beating the poor old horse, --anders
Oct 06 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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.)
Oct 11 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:

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

It's just seem like a BACKWARD choice, considering what others did ? Among all the other modernizations like: obsoleting pointers, changing header files into modules, garbage collected memory, removing the need to sometimes use "->" instead of just "."; we find an ancient C usage like "no boolean" ? Not even the C++ "bool". I think it is great that we have moved forward to C99 and introduced the alias "bool" for the preferred integer type for storing booleans. Even better would be if bool became a reserved and built-in *keyword* (but still arithmetic), like it is in C++. And best would be as in C#: bool as a true/false-only type, that is *not* interchangable with int. Even if some old C/C++ users hate this, it seems to be popular with the new programmers growing up with new languages like C# and Java ? --anders PS. I happen to like C, as I grew up on it. Just thought D was modern.
Oct 11 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Anders F Björklund wrote:

 Walter wrote:
 
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.)

It's just seem like a BACKWARD choice, considering what others did ?

Seems like a fine choice to me. I have no problem with it.
 
 Among all the other modernizations like: obsoleting pointers,
 changing header files into modules, garbage collected memory,
 removing the need to sometimes use "->" instead of just ".";
 
 we find an ancient C usage like "no boolean" ? Not even the C++ "bool".

The C++ bool type and the D bit type are very similiar. Are you saying D doesn't have the equivalent to C++'s bool? Or are you saying that C++'s bool is not a true boolean type?
 
 I think it is great that we have moved forward to C99 and introduced
 the alias "bool" for the preferred integer type for storing booleans.
 Even better would be if bool became a reserved and built-in *keyword*
 (but still arithmetic), like it is in C++. And best would be as in C#:
 
 bool as a true/false-only type, that is *not* interchangable with int.

I think I've heard this before... hmm... let me search the newsgroup... Seriously, though, I'm pretty shocked people consider bit/bool such a big deal. I'm more concerned about the state of D's libraries and tools.
 
 Even if some old C/C++ users hate this, it seems to be popular with
 the new programmers growing up with new languages like C# and Java ?
 
 --anders
 
 
 PS. I happen to like C, as I grew up on it. Just thought D was modern.

Oct 11 2004
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Ben Hinkle wrote:

It's just seem like a BACKWARD choice, considering what others did ?

Seems like a fine choice to me. I have no problem with it.

I can live with it too, if nothing else just to stop this "war" ! I know that "Arcane Jill" came to the same conclusion earlier: digitalmars.D/2973
we find an ancient C usage like "no boolean" ? Not even the C++ "bool".

The C++ bool type and the D bit type are very similiar. Are you saying D doesn't have the equivalent to C++'s bool? Or are you saying that C++'s bool is not a true boolean type?

C++ has a bool type which can be implicitly converted to integer. D has an integer type called "bit". There is a difference here... (even if Walter likes to think that it's all aspects of the Tao) The current state in D is more similar to C99, which has <stdbool.h> It defines "bool" as a macro for _Bool (similar to D's choice of bit), and also defines the constants "true" and "false" as the values 1 and 0. I just wanted a new D keyword "bool", which would be *equal* to bit. (preferrably "bit" should only accept 0/1 and "bool" only false/true, but since they are implicitly converted it doesn't make a difference) * So I am saying that D does not (yet?) have the equivalent of C++ bool. Originally; I said that I wanted a type-safe boolean type like in C#, and have all conditionals *require* this type or throw a "type error". But that new feature can wait for "D 2.0", since it's so controversial. One could even consider a half-way "bool" type that is not *implicitly* converted, but still can be explicitly converted by the use of a cast ? Like most compromises, that "mule" of a bool is neither horse or donkey. * So I am also definitely saying that C++'s bool is not a true boolean. I have no issue whatsoever with the choice of "bit" to represent a bool, I think it makes much more sense than using "char" or "int" like C does. But if true and false are D keywords, then I think bool should be too ? (Or go back to the dark ages of C99 and remove keywords true and false too: "alias bit bool; const bit true = 1; const bit false = 0;". Horror) That's my main point: the current selection of keywords is inconsistent! My rather simple Request For Enhancement was a new D keyword: "bool". (AND to make true and false have this type, which is synonym to bit) NOT to make this type-safe or anything, as that is a *separate* RFE... If that is rejected, I suggest introducing a new stdbool.d like above. (i.e. remove keywords true and false, and just have bits: like 0 and 1) I would vastly prefer the first, but the second is better than current. * Having a C++ "bool" type seems like a good COMPROMISE for D to take ? (compromise between the "extreme" standpoints of C99 and C#, that is)
 Seriously, though, I'm pretty shocked people consider bit/bool such a big
 deal. I'm more concerned about the state of D's libraries and tools.

People are funny that way. The sad part is that it is just hindering D, in favor of the "other languages" in the C family like: C, C++ and C#. I actually think more people are scared off by this war itself, than by D having or not having a boolean type ? Arguments are just so tiring... Just hoped "we" could move further on the evolutionary scale before 1.0: bool evolution: C89 --> C99 --> C++ --> C# ^ D is here Or, wait, Boolean Darwinism is just another religion too - right ? :-P --anders PS. "The following sentence is true. The preceding sentence is false." -- from Zen and the Art of Boolean
Oct 12 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:ckgbj4$bjg$1 digitaldaemon.com...
 Ben Hinkle wrote:

It's just seem like a BACKWARD choice, considering what others did ?

Seems like a fine choice to me. I have no problem with it.

I can live with it too, if nothing else just to stop this "war" ! I know that "Arcane Jill" came to the same conclusion earlier: digitalmars.D/2973

then why the shouting? (typing BACKWARD in all caps is the way one "shouts" in newsgroups and email)
we find an ancient C usage like "no boolean" ? Not even the C++ "bool".

The C++ bool type and the D bit type are very similiar. Are you saying D doesn't have the equivalent to C++'s bool? Or are you saying that C++'s bool is not a true boolean type?

C++ has a bool type which can be implicitly converted to integer. D has an integer type called "bit". There is a difference here... (even if Walter likes to think that it's all aspects of the Tao)

You say "tom-a-to". I say "tom-ah-to". (or maybe I should say "nuclear" and "nucular"). The differences are minor IMO.
 The current state in D is more similar to C99, which has <stdbool.h>
 It defines "bool" as a macro for _Bool (similar to D's choice of bit),
 and also defines the constants "true" and "false" as the values 1 and 0.

 I just wanted a new D keyword "bool", which would be *equal* to bit.
 (preferrably "bit" should only accept 0/1 and "bool" only false/true,
 but since they are implicitly converted it doesn't make a difference)

 * So I am saying that D does not (yet?) have the equivalent of C++ bool.

Sure it doesn't have the exact same C++ semantics but then C++ doesn't have the D data type called "bit".
 Originally; I said that I wanted a type-safe boolean type like in C#,
 and have all conditionals *require* this type or throw a "type error".
 But that new feature can wait for "D 2.0", since it's so controversial.

though the more time passes the less likely bool will change.
 One could even consider a half-way "bool" type that is not *implicitly*
 converted, but still can be explicitly converted by the use of a cast ?
 Like most compromises, that "mule" of a bool is neither horse or donkey.

 * So I am also definitely saying that C++'s bool is not a true boolean.

ok.
 I have no issue whatsoever with the choice of "bit" to represent a bool,
 I think it makes much more sense than using "char" or "int" like C does.
 But if true and false are D keywords, then I think bool should be too ?
 (Or go back to the dark ages of C99 and remove keywords true and false
 too: "alias bit bool; const bit true = 1; const bit false = 0;". Horror)
 That's my main point: the current selection of keywords is inconsistent!

Consistency sounds like a good thing. I can buy the argument that either bool should be a keyword or true/false should not. And actually I'd lean towards defining true/false in object.d right next to the bool alias as you suggest. If someone really really really wants to redefine bool they should be able to redefine true and false.
 My rather simple Request For Enhancement was a new D keyword: "bool".
 (AND to make true and false have this type, which is synonym to bit)
 NOT to make this type-safe or anything, as that is a *separate* RFE...
 If that is rejected, I suggest introducing a new stdbool.d like above.
 (i.e. remove keywords true and false, and just have bits: like 0 and 1)
 I would vastly prefer the first, but the second is better than current.

 * Having a C++ "bool" type seems like a good COMPROMISE for D to take ?
    (compromise between the "extreme" standpoints of C99 and C#, that is)

ok
 Seriously, though, I'm pretty shocked people consider bit/bool such a


 deal. I'm more concerned about the state of D's libraries and tools.

People are funny that way. The sad part is that it is just hindering D, in favor of the "other languages" in the C family like: C, C++ and C#.

I doubt bit/bool is hindering D.
 I actually think more people are scared off by this war itself, than by
 D having or not having a boolean type ? Arguments are just so tiring...

yup.
 Just hoped "we" could move further on the evolutionary scale before 1.0:

 bool evolution:    C89 --> C99 --> C++ --> C#
                              ^
                          D is here

 Or, wait, Boolean Darwinism is just another religion too - right ? :-P

 --anders


 PS.
     "The following sentence is true.
      The preceding sentence is false."
      -- from Zen and the Art of Boolean

Oct 12 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:

It's just seem like a BACKWARD choice, considering what others did ?



then why the shouting? (typing BACKWARD in all caps is the way one "shouts" in newsgroups and email)

I know, I know. Sorry about that... Feel better now.
 Consistency sounds like a good thing. I can buy the argument that either
 bool should be a keyword or true/false should not. And actually I'd lean
 towards defining true/false in object.d right next to the bool alias as you
 suggest. If someone really really really wants to redefine bool they should
 be able to redefine true and false.

Either/or, I think ? A good name for the module would be stdbool.d, since that would make it similar to stdint.d ? module std.stdbool; alias bit bool; const bool true = 1; const bool false = 0; But I would rather have a "bool" keyword like C++. Even if it is still just an alias for the bit type.
* Having a C++ "bool" type seems like a good COMPROMISE for D to take ?
   (compromise between the "extreme" standpoints of C99 and C#, that is)


Oops, shouted again. Time for some therapy, perhaps ? --anders
Oct 12 2004
parent Sean Kelly <sean f4.ca> writes:
In article <ckgt5r$sp4$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
But I would rather have a "bool" keyword like C++.
Even if it is still just an alias for the bit type.

The way I see it, there are two options for D. Either we stick with packed bit values in arrays and D stays pretty much the way it is (maybe even toss the "bool" alias... renaming true/false to on/off has merit but I think would be unnecessarily confusing), or we do away with packed bit values and change the "bit" keyword to "bool." I don't feel that middle ground is appropriate as bool and bit aren't strictly the same thing--one has a physical component while the other is entirely logical. I avoid using "bool" in my D code for exactly this reason--I feel it's misleading. All ideologies aside, I do think that "bit" is consistent with the trend towards fixed-size types in D. My only personal concern is with packed bit behavior, but I haven't made up my mind whether I like it or not. Are the slicing requirements acceptable? Should any attempt be made to enable slicing at all? What about addressing? These are all issues that come up with vector<bool> in C++, but I've found that overload to be more convenient than problematic. Still, I find myself wanting to be able to do things like this: bit[8] a, b; a[0] = 1; b[0] = 1; bit[] c = a + b; What should the result be: an array with all bits zero, or an array with c[1] == 1? In a sense I would expect the latter result, though this would be inconsistent with how vector operations would likely behave for other types, and it seems an unreasonable expectation to put on the compiler. Plus, the effect can already be achieved this way: byte c = cast(byte)*&a[0] + cast(byte)*&b[0]; I really can't decide whether this unique storage property of bit values will turn out to be more of a help or a hindrance as time goes on. It's not something that's ever bothered me personally, either in D or in C++, but I still haven't decided how I feel about this from an idealistic perspective. Sean
Oct 12 2004
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Anders F Björklund wrote:
 Walter wrote:
 ...
 It's by choice. (Though many disagree with that choice.)

bool as a true/false-only type, that is *not* interchangable with int. Even if some old C/C++ users hate this, it seems to be popular with the new programmers growing up with new languages like C# and Java ? --anders PS. I happen to like C, as I grew up on it. Just thought D was modern.

Being "modern", as in stylish, isn't an intrinsic good. Sometimes it is, sometimes it isn't. This time I think it would have been, but it's not my choice. OTOH, it's certainly not too late. You can easily define a new abstract class with two singleton subclasses, each instantiated with a global and give them appropriate mnemonic names (e.g., True and False). This won't be a bit wide, but it's easy enough to define a mapping from bit onto (e.g.) Boolean. The ease with which this could be done is a clear indication that it's not too late, for anyone who cares enough. The firmness of Walter's objections indicates that it won't be a part of the standard language no matter how well you do it. OK. Bit arrays are much more useful than booleans. I'm quite happy to use bit for boolean values. (And when I do get around to writing my own logic class it will have multiple values...probably around 250 of them, excluding error states.)
Oct 14 2004
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Charles Hixson wrote:

 Being "modern", as in stylish, isn't an intrinsic good.  Sometimes it 
 is, sometimes it isn't.  This time I think it would have been, but it's 
 not my choice.

Actually I meant modern as in "high-level". integers-as-bools is so asm?
 OTOH, it's certainly not too late.  You can easily define a new abstract 
 class with two singleton subclasses, each instantiated with a global and 
 give them appropriate mnemonic names (e.g., True and False).  This won't 
 be a bit wide, but it's easy enough to define a mapping from bit onto 
 (e.g.) Boolean.

That wouldn't help much, would it ? Much happier with the "bool" alias, even if it is not type-safe and had some problems with "out" params... I like having my native classes around, without *having* to use Objects.
 OK.  Bit arrays are much more useful than booleans.  I'm quite happy to 
 use bit for boolean values.  (And when I do get around to writing my own 
 logic class it will have multiple values...probably around 250 of them, 
 excluding error states.)

I just fail to see the combining logic behind these two statements: (found on the D overview http://www.digitalmars.com/d/overview.html)
 Features To Drop
 #  Bit fields of arbitrary size.
    Bit fields are a complex, inefficient feature rarely used.

 Bit type
   The fundamental data type is the bit, and D has a bit data type.
   This is most useful in creating arrays of bits:
 	bit[] foo;

Aren't such arrays mostly used precisely to create such bit fields ? Or do such arrays have other uses, like curing bit-operator allergies ? Last time I messed around with 1-bit pixel maps, I just used macros: #define BITSET(p,n) (p)[n >> 3] |= 0x80U >> (n & 7) #define BITCLR(p,n) (p)[n >> 3] &= ~(0x80U >> (n & 7)) #define BITTST(p,n) (((p)[n >> 3] & (0x80U >> (n & 7))) != 0) Maybe it should add: "bits are also useful for emulating booleans" ? ;-) --anders
Oct 14 2004
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Anders F Björklund wrote:
 Charles Hixson wrote:
 
 ...

even if it is not type-safe and had some problems with "out" params...

that singleton classes as their preferred implementation of Bool (under some name or other). You can to the entire logic on that basis. (Since everything False is the same False object, and everything True is the same True object.) You would probably need a bit of syntax around things, though, as the built-in logic tests don't compare the correct way on these objects. You could do it in several different ways, the easiest is to have a val property such that it returns the expected bit value, then one could say if (test.val) {...
 
 I like having my native classes around, without *having* to use Objects.

But the native classes are implemented as Objects anyway, so I don't understand this. If you mean primitive types...well, ok. But those aren't classes any more than they are in C.
 
 OK.  Bit arrays are much more useful than booleans.  I'm quite happy 
 to use bit for boolean values.  (And when I do get around to writing 
 my own logic class it will have multiple values...probably around 250 
 of them, excluding error states.)

I just fail to see the combining logic behind these two statements: (found on the D overview http://www.digitalmars.com/d/overview.html)
 Features To Drop
 #  Bit fields of arbitrary size.
    Bit fields are a complex, inefficient feature rarely used.

and
 Bit type
   The fundamental data type is the bit, and D has a bit data type.
   This is most useful in creating arrays of bits:
     bit[] foo;


question. But here he's talking about bit arrays of arbitrary lenght, I hope, so there will probably continue to be bit arrays. I hope of arbitrary length. (The statement could mean that isolated bit variables won't be packed in a structure. I hope.)
 
 
 Aren't such arrays mostly used precisely to create such bit fields ?

don't know how others use them, but I suspect it depends on what they are doing.
 Or do such arrays have other uses, like curing bit-operator allergies ?
 
 Last time I messed around with 1-bit pixel maps, I just used macros:
 #define BITSET(p,n)    (p)[n >> 3] |= 0x80U >> (n & 7)
 #define BITCLR(p,n)    (p)[n >> 3] &= ~(0x80U >> (n & 7))
 #define BITTST(p,n)    (((p)[n >> 3] & (0x80U >> (n & 7))) != 0)
 
 
 Maybe it should add: "bits are also useful for emulating booleans" ? ;-)
 --anders

Oct 14 2004
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Charles Hixson wrote:

 I like having my native classes around, without *having* to use Objects.

But the native classes are implemented as Objects anyway, so I don't understand this. If you mean primitive types...well, ok. But those aren't classes any more than they are in C.

I meant primitive types, sorry. I love that bool and string are not full-blown objects but built-in. And would like to keep it that way. There could be full "Boolean" and "String" classes too.. Like in Java ? Naturally with full auto-boxing and -unboxing, like in C# and JDK 1.5: int i = 1; Integer o = i; // boxing int j = cast(int) o; // unboxing (Google said: http://www.dotnetextreme.com/articles/cSharpBoxing.asp, also http://java.sun.com/developer/technicalArticles/releases/j2se15) D already has the same (truly awesome!) capability with properties: http://www.digitalmars.com/d/cpptod.html#properties
 That bothers me, too.  I don't have an answer to the implied question.  
 But here he's talking about bit arrays of arbitrary lenght, I hope, so 
 there will probably continue to be bit arrays.  I hope of arbitrary 
 length.  (The statement could mean that isolated bit variables won't be 
 packed in a structure.  I hope.)

I can see that bit[] is a useful language construct, just as char[] is. Just don't think that it should have boolean semantics, but be integers? They are equally pesky to map to bytes, since a bit is 0.125 bytes wide and a char is 1, 2, 3, or 4 bytes wide depending on "how Unicode" it is. As I understand it, an array is stored as a length / byte pointer duple? But I haven't verified this in DMD source code, when it comes to bit[].
 Actually, I usually use bit arrays as arrays of logical values.  I don't 
 know how others use them, but I suspect it depends on what they are doing.

Sounds like bool[] would be more natural for storing a bunch of booleans, just like bit[] could be useful for storing bitmaps ? --anders
Oct 15 2004
prev sibling parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <ckmtds$am9$1 digitaldaemon.com>, Charles Hixson says...
...You can easily define a new 
abstract class with two singleton subclasses, each instantiated with 
a global and give them appropriate mnemonic names (e.g., True and 
False).  This won't be a bit wide, but it's easy enough to define a 
mapping from bit onto (e.g.) Boolean.

All this is completely missing the valid points brought up by Anders Bjoerklund, that for type safety, all conditional statements should require a boolean expression. As far as I know, the only way to attain type safety is to implement it as part of the language definition. Anders pointed out 4 types of conditional statements that he hoped would be illegal for type-safety reasons. Ilya Minkov pointed out that one of these statements was illegal not for type reasons, but because assignment was forbidden. That leaves three. In my message of Oct. 7 I gave examples of errors that are difficult for a programmer to spot, but trivial for a compiler. On Oct. 11 I pointed out that the meaning of a conditional statement depends greatly on the data type, whereas this is not true if a boolean expression is required. I would be happy to be proven wrong on these points, but so far no one has attempted a rebuttal. I suppose the discussion centered on the libraries is an attempt to make the best of the situation without changing the language. But has Walter not already done that? It seems to me that his bool type is about as good as it can be for a type implemented in a library. It's just that I don't see how libraries can possibly achieve type safety. I cannot understand any reason for defining a basic type in a library. In the case of C++, I think it was done as a half-hearted measure because once the language was set in stone, there was no good way to do it. D is about to be set in stone, if it has not been already. As far as I know, no one has pointed out a single disadvantage to type checking conditional statements, and we certainly know of several major disadvantages. D is disadvantaged in this respect to Java, C#, FORTRAN (since at least 1977), all Pascal-family languages, and probably quite a few others. Some view these messages as a war. I would not continue with this message if I were convinced the points were either understood, except by a few, or refuted. I'm not sure the point has gotten across. Somebody please tell me I'm wrong.
Oct 15 2004
next sibling parent reply Rex Couture <Rex_member pathlink.com> writes:
I'm sorry, when I wrote the previous message I had not noticed the thread
entitled "Bits again.  A proposal."  I notice that my remarks are somewhat
parallel to some of the comments in the other thread.

Still, somehow, the conversations always seem to come back to arguments about
bits used as booleans.  Here's an oddity in the computer world:  FORTRAN has at
least two type-compatible boolean types -- 1 byte and 4 bytes.  Maybe 8 bytes
too--I forget.  I don't think it matters much how booleans are defined, as long
as they are part of the language and they are called "boolean", "logical", or
"bool".
Oct 15 2004
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Rex Couture wrote:

 Still, somehow, the conversations always seem to come back to arguments about
 bits used as booleans.  Here's an oddity in the computer world:  FORTRAN has at
 least two type-compatible boolean types -- 1 byte and 4 bytes.  Maybe 8 bytes
 too--I forget.  I don't think it matters much how booleans are defined, as long
 as they are part of the language and they are called "boolean", "logical", or
 "bool".

For reasons of naming compatibility with C99 and C++, I strongly suggest using the name "bool" for the type. (matches "int" for integer, and "char" for character) This (alias) is already in object.d, so the name "bool" should be settled... The underlying type, however, is broken. --anders
Oct 15 2004
prev sibling parent reply larrycowan <larrycowan_member pathlink.com> writes:
In article <ckor2s$2586$1 digitaldaemon.com>, Rex Couture says...
In article <ckmtds$am9$1 digitaldaemon.com>, Charles Hixson says...
...You can easily define a new 
abstract class with two singleton subclasses, each instantiated with 
a global and give them appropriate mnemonic names (e.g., True and 
False).  This won't be a bit wide, but it's easy enough to define a 
mapping from bit onto (e.g.) Boolean.

All this is completely missing the valid points brought up by Anders Bjoerklund, that for type safety, all conditional statements should require a boolean expression. As far as I know, the only way to attain type safety is to implement it as part of the language definition. Anders pointed out 4 types of conditional statements that he hoped would be illegal for type-safety reasons. Ilya Minkov pointed out that one of these statements was illegal not for type reasons, but because assignment was forbidden. That leaves three. In my message of Oct. 7 I gave examples of errors that are difficult for a programmer to spot, but trivial for a compiler. On Oct. 11 I pointed out that the meaning of a conditional statement depends greatly on the data type, whereas this is not true if a boolean expression is required. I would be happy to be proven wrong on these points, but so far no one has attempted a rebuttal. I suppose the discussion centered on the libraries is an attempt to make the best of the situation without changing the language. But has Walter not already done that? It seems to me that his bool type is about as good as it can be for a type implemented in a library. It's just that I don't see how libraries can possibly achieve type safety. I cannot understand any reason for defining a basic type in a library. In the case of C++, I think it was done as a half-hearted measure because once the language was set in stone, there was no good way to do it. D is about to be set in stone, if it has not been already. As far as I know, no one has pointed out a single disadvantage to type checking conditional statements, and we certainly know of several major disadvantages. D is disadvantaged in this respect to Java, C#, FORTRAN (since at least 1977), all Pascal-family languages, and probably quite a few others. Some view these messages as a war. I would not continue with this message if I were convinced the points were either understood, except by a few, or refuted. I'm not sure the point has gotten across. Somebody please tell me I'm wrong.

Can anyone refer us back to something by Walter on this issue with meat in it? i.e., not just "that's the way it is", or "I'm carrying forward this from C".
Oct 15 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
larrycowan wrote:
 In article <ckor2s$2586$1 digitaldaemon.com>, Rex Couture says...
 
In article <ckmtds$am9$1 digitaldaemon.com>, Charles Hixson says...

...You can easily define a new 
abstract class with two singleton subclasses, each instantiated with 
a global and give them appropriate mnemonic names (e.g., True and 
False).  This won't be a bit wide, but it's easy enough to define a 
mapping from bit onto (e.g.) Boolean.

All this is completely missing the valid points brought up by Anders Bjoerklund, that for type safety, all conditional statements should require a boolean expression. As far as I know, the only way to attain type safety is to implement it as part of the language definition. Anders pointed out 4 types of conditional statements that he hoped would be illegal for type-safety reasons. Ilya Minkov pointed out that one of these statements was illegal not for type reasons, but because assignment was forbidden. That leaves three. In my message of Oct. 7 I gave examples of errors that are difficult for a programmer to spot, but trivial for a compiler. On Oct. 11 I pointed out that the meaning of a conditional statement depends greatly on the data type, whereas this is not true if a boolean expression is required. I would be happy to be proven wrong on these points, but so far no one has attempted a rebuttal. I suppose the discussion centered on the libraries is an attempt to make the best of the situation without changing the language. But has Walter not already done that? It seems to me that his bool type is about as good as it can be for a type implemented in a library. It's just that I don't see how libraries can possibly achieve type safety. I cannot understand any reason for defining a basic type in a library. In the case of C++, I think it was done as a half-hearted measure because once the language was set in stone, there was no good way to do it. D is about to be set in stone, if it has not been already. As far as I know, no one has pointed out a single disadvantage to type checking conditional statements, and we certainly know of several major disadvantages. D is disadvantaged in this respect to Java, C#, FORTRAN (since at least 1977), all Pascal-family languages, and probably quite a few others. Some view these messages as a war. I would not continue with this message if I were convinced the points were either understood, except by a few, or refuted. I'm not sure the point has gotten across. Somebody please tell me I'm wrong.

Can anyone refer us back to something by Walter on this issue with meat in it? i.e., not just "that's the way it is", or "I'm carrying forward this from C".

Walter doesn't seem to see any big problems with the bit situation, so he hasn't said much on the issue. A lot of people have said a lot of things on the issue, but I haven't seen any consensus develop. In any case, I've found some of Walter's best posts on bit vs. bool and wiki-ized them: http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit/PostsByWalter Enjoy! -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Oct 15 2004
next sibling parent Rex Couture <Rex_member pathlink.com> writes:
In article <ckpkqj$2sa3$1 digitaldaemon.com>, J C Calvarese says...
In any case, I've found some of Walter's best posts on bit vs. bool and 
wiki-ized them: 
http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit/PostsByWalter

Thanks for collecting those messages. I think most of us have read them before. Unfortunately, I don't see that they address any of the issues we are discussing.
Oct 15 2004
prev sibling parent larrycowan <larrycowan_member pathlink.com> writes:
In article <ckpkqj$2sa3$1 digitaldaemon.com>, J C Calvarese says...
larrycowan wrote:
 In article <ckor2s$2586$1 digitaldaemon.com>, Rex Couture says...
 
In article <ckmtds$am9$1 digitaldaemon.com>, Charles Hixson says...

Can anyone refer us back to something by Walter on this issue with meat in it? i.e., not just "that's the way it is", or "I'm carrying forward this from C".

Walter doesn't seem to see any big problems with the bit situation, so he hasn't said much on the issue. A lot of people have said a lot of things on the issue, but I haven't seen any consensus develop. In any case, I've found some of Walter's best posts on bit vs. bool and wiki-ized them: http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit/PostsByWalter Enjoy! -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/

Thanks. So we have bools as 0:!0, and 0:1 bit arrays to store them but " '='does not give a boolean result " and he's hanging tight on all fronts - some I would side with and some not, but it is not going to move. We can get onto more productive discussions. The wiki4d is a great place to have faq stuff and this needed to be there. Again, thanks.
Oct 15 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 06 Oct 2004 21:46:40 +0200, Ilya Minkov wrote:

 Anders F Björklund schrieb:
 Is it too late to hope for D to get a *real* boolean type ?

 I was hoping for the following code snippets to be illegal:
 
 if (pointer)

Why should that be illegal? I find it very elegant at many cases. Many others also do.

This syntax is just a shorthand for 'if (pointer != null)', but in conceptual terms the 'if' statement syntax should be more like ... IFSTMT :: 'if' '(' boolean_expression ')' statement_block [ 'else' statement_block ] In other words, the expression within the parenthesis should result in a boolean data value. I take the following to be true even if C/C++/D et al disagree somewhat: ** Pointers are not booleans. ** Numbers are not booleans. ** Booleans are not numbers.
 if (a = b) // just a typo!

Assignment in if statement is made illegal and will be rejected by the compiler.

It is odd maybe, that D decides to make this 'concession' but leaves other potential bug makers in place (eg fallthru in switch)
 Instead they could be replaced by the equivalent new code:

 i = (true ? 1 : 0) + 1;

I don't see a reason why this here should be done.

Simple, booleans are not numbers so therefore one cannot do arithmetic on them. What do three truths and a falsehood add up to? It makes no sense does it? What one needs to do is to say, if we substitute each truth with 1 and each falsehood with 0, then 3*T + F = 3. The syntax above makes it clear to the reader of the code that such an arbitary substitution is being carried out. I say 'arbitary' because some systems believe that a truth should be substituted by -1.
 Can it be added/changed, or are we stuck with C9X/C++ bool?

In principle, it is not like anything couldn't be changed by a technical reason, we're not past 1.0 yet. However, such questions have already been discussed dozens, dozens of times with no consensus. Your message doesn't contribute much to the discussion because it fails to provide any argument as to why we should do that. The common typo you show is detected by the compiler. You didn't even check the code you post. -eye

I hope I've help to provide an "argument as to why we should do that". -- Derek Melbourne, Australia 7/10/2004 9:48:43 AM
Oct 06 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:
 I take the following to be true even if C/C++/D et al disagree somewhat:
  ** Pointers are not booleans. 
  ** Numbers are not booleans. 
  ** Booleans are not numbers.

Actually, they all agree on: "there is no boolean" "true" is a number, with the value 1. "false" is a number, with the value 0. "equals true" is the same as "is not zero" "equals false" is the same as "equals zero". And the recommended int type for storing is "bool". --andeers
Oct 07 2004
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 07 Oct 2004 13:51:32 +0200, Anders F Björklund wrote:

 Derek Parnell wrote:
 I take the following to be true even if C/C++/D et al disagree somewhat:
  ** Pointers are not booleans. 
  ** Numbers are not booleans. 
  ** Booleans are not numbers.

Actually, they all agree on: "there is no boolean" "true" is a number, with the value 1. "false" is a number, with the value 0. "equals true" is the same as "is not zero" "equals false" is the same as "equals zero". And the recommended int type for storing is "bool".

I assume your comments above are saying "This is how C sees it..." rather than "This is how it is in the world...", because truth is *not* 1 and falsehood is *not* 0. The designers of C decided to use 1 to represent truth and 0 to represent falsehood. Actually, as you say above, depending on circumstances any non-zero number can be used to represent truth in a C program. But that does not make Truth and Falsehood to be intrinsically numeric. -- Derek Melbourne, Australia 8/10/2004 9:14:22 AM
Oct 07 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:
I take the following to be true even if C/C++/D et al disagree somewhat:

Actually, they all agree on: "there is no boolean"

than "This is how it is in the world...", because truth is *not* 1 and falsehood is *not* 0. The designers of C decided to use 1 to represent truth and 0 to represent falsehood. Actually, as you say above, depending on circumstances any non-zero number can be used to represent truth in a C program. But that does not make Truth and Falsehood to be intrinsically numeric.

I was just talking about those three languages: C(9X), C++, and now D. In all three of those, "true" is a constant number 1 and "false" is a 0 In other languages, such as Forth, true is defined as -1 (=all bits on) Size of "bool" varies, but usually: 1 bit,8 bits (char),or 32 bits (int) I was *all for* introducing a proper boolean class, non-arithmethic... And then make all conditionals require and comparisons return this type. Just like the way that it works in Java, see that language for examples. But it seems like D prefers to handle logic "numerically", like C/C++ ? In D, you use the inttype "bit" and the values "1" and "0" for booleans. Or use their aliases: "bool", "true", "false" but that's just aesthetic Another way of putting it: Q. Too late for boolean ? A. Yes. --anders
Oct 07 2004
next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 08 Oct 2004 02:28:34 +0200, Anders F Björklund wrote:

[snip]

 Another way of putting it:
 Q. Too late for boolean ?
 A. Yes.

Sadly, I suspect you are correct with that summary. I think that while Walter has ultimate control over the D specification that a true (text-book) boolean data type will never surface. Eventually, when /bool/ does arrive as an intrinsic type, they will be too afraid of breaking existing code to disallow arithmetic operations on it. So yes, the horse has bolted and shutting-the-gate time has already passed us by. -- Derek Melbourne, Australia 8/10/2004 10:36:16 AM
Oct 07 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ck4n04$d4p$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Another way of putting it:
Q. Too late for boolean ?
A. Yes.

I prophesize the opposite. True - for so long as Walter controls the spec, we are unlikely to have a boolean bool. However, if D is successful (as we hope it will be) then the time will come when standards committees such as ISO and the like will take over the spec. At that time, bool will be added. It's a bummer that we probably won't see it before then, but that's how it is. Jill PS. Here at the Church of Typesafety, we also hold as dogma and eternal truth that **a character is not a number; a character is not a boolean; and a character is not a pointer**. I seem to be alone in that opinion, however, so I'll shut up before another thread spawns.
Oct 07 2004
next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 8 Oct 2004 06:33:57 +0000 (UTC), Arcane Jill wrote:

 In article <ck4n04$d4p$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Another way of putting it:
Q. Too late for boolean ?
A. Yes.

I prophesize the opposite. True - for so long as Walter controls the spec, we are unlikely to have a boolean bool. However, if D is successful (as we hope it will be) then the time will come when standards committees such as ISO and the like will take over the spec. At that time, bool will be added. It's a bummer that we probably won't see it before then, but that's how it is. Jill PS. Here at the Church of Typesafety, we also hold as dogma and eternal truth that **a character is not a number; a character is not a boolean; and a character is not a pointer**. I seem to be alone in that opinion, however, so I'll shut up before another thread spawns.

Well not /so/ alone. I believe as you do re characters. Computer systems use numbers to represent characters, but that is only a representation and not the character itself. So maybe UniCode can be seen as one (of many) protocols that represent characters using numbers. And utf8, utf16, utf32, etc... are various implementations of that protocol. -- Derek Melbourne, Australia 8/10/2004 5:18:31 PM
Oct 08 2004
prev sibling next sibling parent Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <ck5ccl$tit$1 digitaldaemon.com>, Arcane Jill says...

PS. Here at the Church of Typesafety, we also hold as dogma and eternal truth
that **a character is not a number; a character is not a boolean; and a
character is not a pointer**. I seem to be alone in that opinion, however, so
I'll shut up before another thread spawns.

You're not alone. We are many. And eventually we'll win. Ciao
Oct 08 2004
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Arcane Jill wrote:

 PS. Here at the Church of Typesafety, we also hold as dogma and eternal truth
 that **a character is not a number; a character is not a boolean; and a
 character is not a pointer**. I seem to be alone in that opinion, however, so
 I'll shut up before another thread spawns.

Java, as I used as a basis for the "boolean" question, does worship both the "boolean" and "pointer" deities: - boolean is not a number (avoiding the legacy "bool") You need to compare numbers against zero: if (i!=0) - pointer is not a number (they call them references) You need to compare them against null: if (p!=null) However, then they went ahead and defined "char" as an integer between 0x0000 and 0xFFFF - which was fine for Unicode-at-the-time, which only knew about UTF-16. Now, when Unicode is up to v4.0.1 and UTF-32 is here Java is in almost as much trouble as C - who defined a character to be in the area of 0x00-0x7F (signed)... So it seems they both paid for *that* particular blasphemy ? You should only compare characters against NUL: if (c!='\0') --anders PS. I won't even *ask* for a (32-bit) "character" and char, wchar and dchar dying a nasty ugly death. But *if* it should happen, I wouldn't mourn... Working with "fragments" just makes my head hurt. I would have preferred a (builtin) "string" type. But I do know that Walter is against that too...
Oct 08 2004
prev sibling parent reply Rex Couture <Rex_member pathlink.com> writes:
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.
Oct 08 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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"
Oct 08 2004
parent Rex Couture <Rex_member pathlink.com> writes:
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.
Oct 08 2004
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <ck1gtq$14r$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Is it too late to hope for D to get a *real* boolean type ?

Depends on what you're proposing.
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)

Unlikely. This is too important for C source compatibility.
if (a = b) // just a typo!
if (c = readchar())

These are already both illegal.
i = true + 1;

Messy, but this is even legal in C/C++.
Instead they could be replaced by the equivalent new code:

if (pointer != null)

Arguably a good idea.
if (a == b) // what was meant!
if ((c = readchar()) != 0)

Already necessary.
i = (true ? 1 : 0) + 1;

I like this too.
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?

Until D is standardized, anything is possible. But this is a religious issue that has been discussed to death. If anything is likely to change Walter's mind about "bit" it's that implementing arrays and slicing and such turned out to be more complex than expected, and it may not be worth the trouble for what could also be implemented in a library class.
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")

I don't think the size of bool should matter, though it would be nice if it were always one byte (just for the sake of storage). The C++ standard, however, doesn't place any storage requirements on bool, so 4 bytes is fair game.
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 ?

C source code compatibility is an issue, to a degree. Walter has tried to keep behavior consistent whenever doing so doesn't result in undesired behavior. It's what constitutes undesired behavior that's sometimes an issue of contention. Sean
Oct 06 2004
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Sean Kelly wrote:
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")

I don't think the size of bool should matter, though it would be nice if it were always one byte (just for the sake of storage). The C++ standard, however, doesn't place any storage requirements on bool, so 4 bytes is fair game.

Yeah, implementing a "bool" in C can be a bit tricky ? Whether to choose "char" for size or "int" for speed... "bit" is a lot easier. It's always 0.125 byte. :-) --anders
Oct 06 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ck1gtq$14r$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
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.

In my time on this forum, this has to qualify as /the/ most Frequently Asked Question we ever hear. Can't we just put it in the actual FAQ at http://www.digitalmars.com/d/faq.html and be done with it? Q. Why doesn't D have a real boolean type? A. Walter doesn't like it. Arcane Jill
Oct 07 2004
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Arcane Jill wrote:

 In my time on this forum, this has to qualify as /the/ most Frequently Asked
 Question we ever hear. Can't we just put it in the actual FAQ at
 http://www.digitalmars.com/d/faq.html and be done with it?

I did see the *question* a lot, just not any answers... :-) The discussion seemed more to be about the size of "bool" ?
 Q. Why doesn't D have a real boolean type?
 A. Walter doesn't like it.

OK, "bit" it is then... (With the "bool" syntactic sugar) Just as how it usually works, in C/C++: "non-zero is true" Too bad, --anders
Oct 07 2004
prev sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Arcane Jill wrote:

 In article <ck1gtq$14r$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
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.

In my time on this forum, this has to qualify as /the/ most Frequently Asked Question we ever hear. Can't we just put it in the actual FAQ at http://www.digitalmars.com/d/faq.html and be done with it? Q. Why doesn't D have a real boolean type? A. Walter doesn't like it. Arcane Jill

Putting it in the FAQ is fine but I assume you weren't serious about the answer "Walter doesn't like it". Walter must have some snippets scattered about with a better rationale.
Oct 07 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Ben Hinkle wrote:
 Arcane Jill wrote:
 
 
In article <ck1gtq$14r$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

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.

In my time on this forum, this has to qualify as /the/ most Frequently Asked Question we ever hear. Can't we just put it in the actual FAQ at http://www.digitalmars.com/d/faq.html and be done with it? Q. Why doesn't D have a real boolean type? A. Walter doesn't like it. Arcane Jill

Putting it in the FAQ is fine but I assume you weren't serious about the answer "Walter doesn't like it". Walter must have some snippets scattered about with a better rationale.

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 works right now. If someone wants to do some research on the various bit/bool discussions over the years, this might be a good place to start: http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit The topic should be mentioned in the official FAQ because it's definitely frequently asked and I think AJ's answer is as good as any. Here's another suggested answer: "If you don't like it, you can complain, but you shouldn't expect it to change much. You're not the first to broach the subject." I guess I'm an Agnostic with respect to bit/bool. I just use bit, and call it good. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Oct 07 2004
next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
J C Calvarese wrote:

 Ben Hinkle wrote:
 Arcane Jill wrote:
 
 
In article <ck1gtq$14r$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

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.

In my time on this forum, this has to qualify as /the/ most Frequently Asked Question we ever hear. Can't we just put it in the actual FAQ at http://www.digitalmars.com/d/faq.html and be done with it? Q. Why doesn't D have a real boolean type? A. Walter doesn't like it. Arcane Jill

Putting it in the FAQ is fine but I assume you weren't serious about the answer "Walter doesn't like it". Walter must have some snippets scattered about with a better rationale.

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.

lol - Amen to that.
 I don't think Walter has written much other than he likes the way it
 works right now.
 
 If someone wants to do some research on the various bit/bool discussions
 over the years, this might be a good place to start:
 http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit

good link. I'll check out the posts.
 The topic should be mentioned in the official FAQ because it's
 definitely frequently asked and I think AJ's answer is as good as any.
 Here's another suggested answer: "If you don't like it, you can
 complain, but you shouldn't expect it to change much. You're not the
 first to broach the subject."
 
 I guess I'm an Agnostic with respect to bit/bool. I just use bit, and
 call it good.
 

It would be interesting to see the notes from the C++ standard discussions. In this area C++ is the closest to D than Java/C#/Python/etc.
Oct 07 2004
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
J C Calvarese wrote:
 Ben Hinkle wrote:
 
 Arcane Jill wrote:
...

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 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.)
Oct 08 2004
prev sibling next sibling parent Rex Couture <Rex_member pathlink.com> writes:
There seems to be confusion as to what is really wrong with the following code
snippets (note that I have added an example).

The real problem is that D syntax forces the programmer to remember the data
type, and this will inevitably lead to errors, some of which will not be found
during debugging.


#  if (pointer)...; // I forgot it was a pointer!  Disaster
#  i = trueVariable + 1;  //I thought this was an integer

#  int data;
#  boolean bData;
#  if (data)...  // I thought this was boolean too
Oct 07 2004
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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 ?

Oct 08 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Oct 09 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
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
Oct 09 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.


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.
Oct 11 2004
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:

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


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.
Oct 11 2004
prev sibling next sibling parent Mike Swieton <mike swieton.net> writes:
On Mon, 11 Oct 2004 02:30:31 -0700, Walter wrote:

 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.

We're not at gate level though. If we wanted to be working on gates, we'd wouldn't be using a language like D.
 The D 'bit' type is a true boolean - it can only contain two values.

I'm not certain that that argument works: just because it can have only two values, doesn't mean it's meaningful for representing _any_ given two values. That is, 0 and 1 are false and true, respectively, only by convention. A convention which came up because of logic gate design (see above). On the other hand, 'true' is true, pretty much by definition. To say that one is the accepted substitution for another is not to admit that they're equivalent. A small thought experiment: if bit represented either 18 or -12, two discrete values, instead of 0 and 1, then which would be true and which would be false? If you can't answer that in an indisputable manner, than the 'only two values' argument doesn't hold up. I admit, I don't really care too much about the boolean issue. But I think that argument in particular, Walter, doesn't hold water. Mike Swieton __ The perversity of the Universe tends towards a maximum. - O'Tool's Corollary of Finagle's Law
Oct 11 2004
prev sibling next sibling parent reply Derek <derek psyc.ward> writes:
On Mon, 11 Oct 2004 02:30:31 -0700, Walter wrote:

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


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.

I'm not knowledgeable enough to answer this, but can you add, in the arithmetic sense, two or more voltage levels?
 The D 'bit' type is a true boolean - it can only contain two values.

This is a true statement (excuse the pun). However, it is not a complete statement of the truth. Although 'bit' is boolean in terms of its potential values, it is a superset of boolean in that you can do things with bit that you can't (or shouldn't) do with booleans values. Such as arithmetic. -- Derek Melbourne, Australia
Oct 11 2004
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek wrote:

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.

I'm not knowledgeable enough to answer this, but can you add, in the arithmetic sense, two or more voltage levels?

That all works just fine, in D: void main() { printf("5V + 5V = %dV\n", 5 + 5); printf("1 + 1 = %d\n", 1 + 1); printf("true + true = %d\n", true + true); } All the same, like Walter said :-) --anders
Oct 11 2004
parent reply Derek <derek psyc.ward> writes:
On Mon, 11 Oct 2004 16:13:33 +0200, Anders F Björklund wrote:

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

I'm not knowledgeable enough to answer this, but can you add, in the arithmetic sense, two or more voltage levels?

That all works just fine, in D: void main() { printf("5V + 5V = %dV\n", 5 + 5); printf("1 + 1 = %d\n", 1 + 1); printf("true + true = %d\n", true + true); } All the same, like Walter said :-)

I guess I didn't make myself clear (again). If we say that -12V is True, and +12V is False, can we add them together to get 0V? And if so, is that result True or False or something else? This is a compile-time issue I think. The compiler should prevent people trying to do arithmetic with boolean values. I'm not adverse to explicit casts as this is telling the coder reader that the author knew what they were doing and it is deliberate. The implicit cast to int for bool in D is an issue. Thus ...
    printf("true + true = %d\n", cast(int)true + cast(int)true);

would be a deliberate statement by the code author. -- Derek Melbourne, Australia
Oct 11 2004
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek wrote:

 This is a compile-time issue I think. The compiler should prevent people
 trying to do arithmetic with boolean values. I'm not adverse to explicit
 casts as this is telling the coder reader that the author knew what they
 were doing and it is deliberate. The implicit cast to int for bool in D is
 an issue.
 
 Thus ...
 
   printf("true + true = %d\n", cast(int)true + cast(int)true);

would be a deliberate statement by the code author.

Probably even better to disallow *any* cast from boolean to integer ? That's the way it currently works in the Java language:
 Found 2 semantic errors compiling "test.java":
 
      5.     System.out.println((int) true + (int) true);
                                      ^--^
 *** Semantic Error: An expression of type "boolean" cannot be cast into type
"int".
 
      5.     System.out.println((int) true + (int) true);
                                                   ^--^
 *** Semantic Error: An expression of type "boolean" cannot be cast into type
"int".

However, the canonical way of writing it in Java is: System.out.println((true ? 1 : 0) + (true ? 1 : 0)); Which works in C / C++ / D too, with their arithmetic/numeric logic... --anders PS. The D compiler *does* prevent you from doing logic with numbers. Such as the good old "if (a = b)" typo. (when you meant: "a==b")
   '=' does not give a boolean result

Oct 11 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:ckebgf$1mne$1 digitaldaemon.com...
 However, the canonical way of writing it in Java is:

      System.out.println((true ? 1 : 0) + (true ? 1 : 0));

No thanks :-)
Oct 11 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:

     System.out.println((true ? 1 : 0) + (true ? 1 : 0));

No thanks :-)

I would say adding two booleans was a pretty contrived example... It's actually not that big a change, especially not from C99/C++. I've ported some C/C++ code to Java, and you usually just change: if (!pointer) --> if (pointer == null) if (integer) --> if (integer != 0) while (character) --> while (character != '\0') flag |= boolean << SHIFT; --> flag |= (boolean ? 1 : 0) << SHIFT; There is *nothing* stopping us from making such code changes already? Even if all we have is a "bool" type... We do have "true" and "false". If it's the same to you Walter, I do suggest two rather minor changes: 1) Make the type (if there is one ?) of "true" and "false" into "bool" (true and false are keywords, but I do think they are "bit" now?) 2) Make the default value for bit "0", and not "false" like it is now. http://www.digitalmars.com/d/type.html - Default Initializer (.init) That would allow for a GRADUAL change for D - from the current C99 bool usage into the new type-safe bool usage that C# (of all languages) has? As long as bit only has the values 1 and 0, and bool only has true/false all we are missing at the moment are some compiler checks and warnings? While I am it, could we make the alias "bool" into a reserved D keyword? (since it's in the system headers anyway, and "true" and "false" are kw) Ecumenic greetings, --anders PS. It's interesting to see that the compiler does check conditionals for boolean expressions already, even if there is no boolean type. Makes you wonder how much work it would be to make this D change ? (if anyone should want to go ahead and prepare the patch, I mean)
Oct 11 2004
parent reply Daniel Horn <hellcatv hotmail.com> writes:
 It's actually not that big a change, especially not from C99/C++.
 I've ported some C/C++ code to Java, and you usually just change:
 
 if (!pointer)
 -->    if (pointer == null)

don't want to call opEqual do you? better "triple" check it's null if (pointer === null)
 if (integer)
 -->    if (integer != 0)
 while (character)
 -->    while (character != '\0')
 flag |= boolean << SHIFT;
 -->    flag |= (boolean ? 1 : 0) << SHIFT;
 
 PS. It's interesting to see that the compiler does check conditionals
     for boolean expressions already, even if there is no boolean type.
 
     Makes you wonder how much work it would be to make this D change ?
     (if anyone should want to go ahead and prepare the patch, I mean)

Oct 11 2004
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Daniel Horn wrote:

 if (!pointer)
 -->    if (pointer == null)

porting java code to D gets even trickier don't want to call opEqual do you? better "triple" check it's null if (pointer === null)

I'm new here. :-) Am I right in believing that == and != should be used with pointers, and that === and !== should be used with references (avoiding *NULL) ? --anders
Oct 12 2004
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Derek wrote:
 On Mon, 11 Oct 2004 16:13:33 +0200, Anders F Björklund wrote:
 
 
Derek wrote:


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.

I'm not knowledgeable enough to answer this, but can you add, in the arithmetic sense, two or more voltage levels?

That all works just fine, in D: void main() { printf("5V + 5V = %dV\n", 5 + 5); printf("1 + 1 = %d\n", 1 + 1); printf("true + true = %d\n", true + true); } All the same, like Walter said :-)

I guess I didn't make myself clear (again). If we say that -12V is True, and +12V is False, can we add them together to get 0V? And if so, is that result True or False or something else? This is a compile-time issue I think. The compiler should prevent people trying to do arithmetic with boolean values. I'm not adverse to explicit casts as this is telling the coder reader that the author knew what they were doing and it is deliberate. The implicit cast to int for bool in D is an issue. Thus ...
   printf("true + true = %d\n", cast(int)true + cast(int)true);

would be a deliberate statement by the code author.

Are you asking about how ports and transistors work physically? In that case the answer to your question, in short, is no. If I remember my dig.tech. correctly, a value (bit) is decided by the voltage in some unit, 0V equals 0 and 3-5V (depending on the processor, actually) equals 1. Then you move these bits around through ports made of transistors. Different ports can do different things, but among the most common are XOR, AND, NAND. Most of them (all?) take two inputs and has an output. One such port (or was it gate?) can only produce a one bit result. Thus to be able to add larger numbers you need to have many bits and bytes and gates and ports and put them together in a smart way. I hope I answered the correct question in a somewhat understandable way :) Lars Ivar Igesund
Oct 11 2004
parent "Walter" <newshound digitalmars.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:ckekr7$1vcf$1 digitaldaemon.com...
 Are you asking about how ports and transistors work physically? In that
 case the answer to your question, in short, is no.
 If I remember my dig.tech. correctly, a value (bit) is decided by the
 voltage in some unit, 0V equals 0 and 3-5V (depending on the processor,
 actually) equals 1. Then you move these bits around through ports made
 of transistors. Different ports can do different things, but among the
 most common are XOR, AND, NAND. Most of them (all?) take two inputs and
 has an output. One such port (or was it gate?) can only produce a one
 bit result. Thus to be able to add larger numbers you need to have many
 bits and bytes and gates and ports and put them together in a smart way.
 I hope I answered the correct question in a somewhat understandable way :)

Back when I was a kid, I had a toy where you set some mechanical flip flops up with a 'program' and then rolled marbles down, which flowed through the 'program' gates and operated the flip flops. You could set it up for several operations, like doing a binary add.
Oct 11 2004
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <29gc8s0lsj54.1lob303fnjsv0$.dlg 40tude.net>, Derek says...
I'm not knowledgeable enough to answer this, but can you add, in the
arithmetic sense, two or more voltage levels? 

Certainly. AFAIK the early computers were all base 10. But boolean math is much easier to implement in modern hardware. Sean
Oct 11 2004
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
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.

Well, wasn't this all about typesafety? Anyway, I don't get you. At the end everything in the computer is high and low voltage, so should we stop thinking in functions, objects and the like and rather think in some binary format? Why do we actualy use a high level language? We want to abstract things to a level at which things get easy for humans. We aren't interested whether it's all 1 and 0 for the computer. -- Matthias Becker
Oct 11 2004
prev sibling parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <ck85pc$5gl$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
It's not type-safe. Some people think that's a bad thing.

It is a bad thing. I would go further and say that if we can't agree on the need for type safety by the year 2004, then we haven't learned very much. You can't promote a new language for the 21st century that bypasses type safety. The issue of the size of a boolean variable is another issue, which is stricly a matter of implementation. It makes no logical difference whether a boolean variable is 1 bit or more. You can even have more than one size of type-compatible boolean, which is now the case -- as long as a boolean expression is required for a conditional statement, which is not now the case.
Oct 11 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Rex Couture wrote:

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


 It is a bad thing.  I would go further and say that if we can't agree on the
 need for type safety by the year 2004, then we haven't learned very much.  You
 can't promote a new language for the 21st century that bypasses type safety.

Guess you could say the same of pointers, goto, or even compiled code ? As in: if you want Java or C#, you know from which best-buddy companies. Walter made his choice. --anders
Oct 11 2004
parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <cke4ui$1fvs$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Rex Couture wrote:
...if we can't agree on the
 need for type safety by the year 2004, then we haven't learned very much. 
>>You can't promote a new language for the 21st century that bypasses type
>>safety.

Guess you could say the same of pointers, goto, or even compiled code ?

You're missing the point. In the case of boolean expressions in conditional statements, by allowing integers as booleans we are not only giving up type checking, but we are giving up the possibility of type checking. Under current rules, the compiler simply cannot check whether you have used the correct data type. Walter has given two reasons of which I am aware, for the structure of booleans. First, checking an integer for a 0 value is fast, and faster than checking it for a 0 or 1 value. This has nothing to do with type checking for boolean expressions at compile time, but it has confused the discussion. No one has yet demonstrated how type checking could possibly affect performance. If I understand Walter correctly, the real reason is so D will compile C code without modification. The price for this is that you can't type-check your shiny new code either. Equally bad, if previous C code is sufficiently long to involve a major effort to fix boolean expressions, you will almost certainly compile errors right along with the good code. I don't find either to be a very satisfactory situation. In the opinions of many people, these situations do not reflect good coding practice. I note that several members of this discussion group can't wait for D++ or some such, so we can change the situation. It remains to be seen whether this is realistic.
Oct 11 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Rex Couture wrote:

Guess you could say the same of pointers, goto, or even compiled code ?

You're missing the point. In the case of boolean expressions in conditional statements, by allowing integers as booleans we are not only giving up type checking, but we are giving up the possibility of type checking. Under current rules, the compiler simply cannot check whether you have used the correct data type.

Yeah, that is why I *started* this thread - asking for a real boolean ;) I wanted a non-arithmetic "boolean" like in Java, not "bool" as in C/C++
 Walter has given two reasons of which I am aware, for the structure of
booleans.
 First, checking an integer for a 0 value is fast, and faster than checking it
 for a 0 or 1 value.  This has nothing to do with type checking for boolean
 expressions at compile time, but it has confused the discussion.  No one has
yet
 demonstrated how type checking could possibly affect performance.

That argument just sounds like a case of premature optimization to me... I'm not sure why boolean couldn't be *implemented* the same way as bit ?
 If I understand Walter correctly, the real reason is so D will compile C code
 without modification.  The price for this is that you can't type-check your
 shiny new code either.  Equally bad, if previous C code is sufficiently long to
 involve a major effort to fix boolean expressions, you will almost certainly
 compile errors right along with the good code.  I don't find either to be a
very
 satisfactory situation.  In the opinions of many people, these situations do
not
 reflect good coding practice.

D breaks with other C code on purpose, so that argument doesn't hold. http://www.digitalmars.com/d/overview.html says: "C source code compatibility. Extensions to C that maintain source compatibility have already been done (C++ and ObjectiveC). Further work in this area is hampered by so much legacy code it is unlikely that significant improvements can be made." I think the real reason is that Walter *prefers* the "sloppy" C syntax ?
 I note that several members of this discussion group can't wait for D++ or some
 such, so we can change the situation.  It remains to be seen whether this is
 realistic.

I gave up, and moved on. If I can live with "bool" in C/C++, I can in D. --anders
Oct 11 2004
parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <ckenm4$21c1$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Yeah, that is why I *started* this thread - asking for a real boolean ;)
I wanted a non-arithmetic "boolean" like in Java, not "bool" as in C/C++

My apologies, I guess I misunderstood your message, and I certainly forgot who wrote what.
http://www.digitalmars.com/d/overview.html says:
"C source code compatibility...."

I think the real reason is that Walter *prefers* the "sloppy" C syntax ?

You're right. In the language overview, he argues rightly for source-code compatibility as a feature to drop.
I gave up, and moved on. If I can live with "bool" in C/C++, I can in D.

My suggestion is (gasp) Hungarian notation.
Oct 11 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Rex Couture wrote:

I gave up, and moved on. If I can live with "bool" in C/C++, I can in D.

My suggestion is (gasp) Hungarian notation.

Are you talking about something like this, perhaps ? bit bFlag = true; I'm not sure how the hungarian warts would help here ? And if you are, then I want nothing to do with it :-) --anders
Oct 11 2004
next sibling parent Sjoerd van Leent <svanleent wanadoo.nl> writes:
Anders F Björklund wrote:
 I'm not sure how the hungarian warts would help here ?
 And if you are, then I want nothing to do with it :-)
 
 --anders

I'm with you. Hungarian notation is just ugly, plain ugly, nothing more but sure nothing less than ugly. Regards, Sjoerd
Oct 11 2004
prev sibling parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <ckerfa$2484$2 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Rex Couture wrote:
 My suggestion is (gasp) Hungarian notation.

I'm not sure how the hungarian warts would help here ?

Simple. # if (bVariable) ... # if (pDeceptiveVariableName !=0) ... at least allow you to see that you are using valid boolean expressions, and not some kind of integer or pointer, even if the compiler cannot check it. ============================================ Note that # if (DeceptiveVariableName) ... is now legal, even if it's a pointer, an integer, or boolean. Good luck trying to read the code. The meaning depends on the variable type! ============================================ If the compiler can't do type checking, then the programmer must, as ugly as that may be. Are you SURE the bool type solves your problems? See what I mean?
Oct 11 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Rex Couture wrote:

 Simple.
 #  if (bVariable) ...
 #  if (pDeceptiveVariableName !=0) ...
 at least allow you to see that you are using valid boolean expressions, and not
 some kind of integer or pointer, even if the compiler cannot check it.

This cure is worse than the disease. Either the compiler checks the types of the variables, or no-one does...
 Note that
 #  if (DeceptiveVariableName) ...
 is now legal, even if it's a pointer, an integer, or boolean.  Good luck trying
 to read the code.  The meaning depends on the variable type!

Nah, it has the same meaning for all: check for non-zero. Real Programmers *know* that NULL is 0 and false is 0...
 If the compiler can't do type checking, then the programmer must, as ugly as
 that may be.  Are you SURE the bool type solves your problems?  See what I
mean?

If logic is arithmetic, there is no *need* to check types. It's also a little less "safe" than having separate types. --anders PS. Real Programmers don't eat quiche, either. http://www.ee.ryerson.ca:8080/~elf/hack/realmen.html
Oct 11 2004
parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <ckeub6$26h5$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Rex Couture wrote:

 Simple.
 #  if (bVariable) ...
 #  if (pDeceptiveVariableName !=0) ...
 at least allow you to see that you are using valid boolean expressions, and not
 some kind of integer or pointer, even if the compiler cannot check it.

This cure is worse than the disease. Either the compiler checks the types of the variables, or no-one does...

Exactly.
 Note that
 #  if (DeceptiveVariableName) ...
 is now legal, even if it's a pointer, an integer, or boolean.  Good luck trying
 to read the code.  The meaning depends on the variable type!

Nah, it has the same meaning for all: check for non-zero. Real Programmers *know* that NULL is 0 and false is 0...

I think you're joking. Just in case, the significance of the 0 or nonzero result depends strongly on the type.
PS. Real Programmers don't eat quiche, either.
     http://www.ee.ryerson.ca:8080/~elf/hack/realmen.html

Now I know you're joking. This is a classic spoof. Speaking as someone who has used card punches and FORTRAN IV, I can attest that Real Programmers have crashed a few multimillion dollar space probes.
Oct 11 2004
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Rex Couture wrote:

Nah, it has the same meaning for all: check for non-zero.
Real Programmers *know* that NULL is 0 and false is 0...

I think you're joking. Just in case, the significance of the 0 or nonzero result depends strongly on the type.

Not to the computer, it doesn't. :-) (yes, I was half-joking)
 Now I know you're joking.  This is a classic spoof.  Speaking as someone who
has
 used card punches and FORTRAN IV, I can attest that Real Programmers have
 crashed a few multimillion dollar space probes.

I guess "Real Programmers aren't afraid of live beta tests" ? --anders
Oct 12 2004