www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Shouldn't bool be initialized to 0xFF ?

reply Lionello Lunesu <lio lunesu.remove.com> writes:
I've been following those "why's char init'ed to -1?" / "why's float 
init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
initialization sure makes it obvious where the problem lies.

So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, bool.init 
is 0, which is a valid value for bool. For byte/int/long I get it, since 
there is no invalid value for byte/int/long. But for bool there is, so 
the same reasoning as char/float applies.

We could even name 0xFF "Not A Bool" ;)

L.
Aug 15 2006
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Lionello Lunesu wrote:
 I've been following those "why's char init'ed to -1?" / "why's float 
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
 initialization sure makes it obvious where the problem lies.
 
 So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, bool.init 
 is 0, which is a valid value for bool. For byte/int/long I get it, since 
 there is no invalid value for byte/int/long. But for bool there is, so 
 the same reasoning as char/float applies.
 
 We could even name 0xFF "Not A Bool" ;)

There is a difference here. For char, 0xff is a valid value. That is, the spec says a char may hold the value 0xff - possibly to represent an illegal character. Likewise for NaN. NaN is a well defined value for floating point types. It is within the types value range. A bool may never hold any other value than 0 or 1. This is enforced by the compiler. No other value than 0 or 1 is within the bool value range. The bool is the only type I know of where the compiler forces a value range below the possible physical storage range. /Oskar
Aug 15 2006
next sibling parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Tue, 15 Aug 2006 17:09:16 +0300, Oskar Linde  
<oskar.lindeREM OVEgmail.com> wrote:
 Lionello Lunesu wrote:
 I've been following those "why's char init'ed to -1?" / "why's float  
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy  
 initialization sure makes it obvious where the problem lies.
  So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, bool.init  
 is 0, which is a valid value for bool. For byte/int/long I get it,  
 since there is no invalid value for byte/int/long. But for bool there  
 is, so the same reasoning as char/float applies.
  We could even name 0xFF "Not A Bool" ;)

There is a difference here. For char, 0xff is a valid value. That is, the spec says a char may hold the value 0xff - possibly to represent an illegal character. Likewise for NaN. NaN is a well defined value for floating point types. It is within the types value range. A bool may never hold any other value than 0 or 1. This is enforced by the compiler. No other value than 0 or 1 is within the bool value range. The bool is the only type I know of where the compiler forces a value range below the possible physical storage range. /Oskar

What if the compiler wouldn't enforce the value to be 0 or 1 in bool.init? This way the initial value could be 0xFF indicating that a variable is not initialized by the user.
Aug 15 2006
prev sibling next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Oskar Linde wrote:
 Lionello Lunesu wrote:
 I've been following those "why's char init'ed to -1?" / "why's float 
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
 initialization sure makes it obvious where the problem lies.

 So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, bool.init 
 is 0, which is a valid value for bool. For byte/int/long I get it, 
 since there is no invalid value for byte/int/long. But for bool there 
 is, so the same reasoning as char/float applies.

 We could even name 0xFF "Not A Bool" ;)

There is a difference here. For char, 0xff is a valid value. That is, the spec says a char may hold the value 0xff - possibly to represent an illegal character. Likewise for NaN. NaN is a well defined value for floating point types. It is within the types value range.

For float, I'd have to agree with you. But, for char, the spec says it's an UTF8 string, and 0xFF is clearly invalid in UTF8. The 'physical storage' of char allows for the 0xFF to be used as a initializer to catch uninited data. And I guess the same can be applied to bool.
 A bool may never hold any other value than 0 or 1. This is enforced by
 the compiler. No other value than 0 or 1 is within the bool value
 range. The bool is the only type I know of where the compiler forces a
 value range below the possible physical storage range.

You're citing the spec, when I'm actually suggestion an addition to the spec. Sound like a logical fallacy to me (but which one? anyone?) L.
Aug 15 2006
prev sibling parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Tue, 15 Aug 2006 17:09:16 +0300, Oskar Linde
<oskar.lindeREM OVEgmail.com> wrote:
 Lionello Lunesu wrote:
 I've been following those "why's char init'ed to -1?" / "why's float  
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy  
 initialization sure makes it obvious where the problem lies.
  So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, bool.init  
 is 0, which is a valid value for bool. For byte/int/long I get it,  
 since there is no invalid value for byte/int/long. But for bool there  
 is, so the same reasoning as char/float applies.
  We could even name 0xFF "Not A Bool" ;)

There is a difference here. For char, 0xff is a valid value. That is, the spec says a char may hold the value 0xff - possibly to represent an illegal character. Likewise for NaN. NaN is a well defined value for floating point types. It is within the types value range. A bool may never hold any other value than 0 or 1. This is enforced by the compiler. No other value than 0 or 1 is within the bool value range. The bool is the only type I know of where the compiler forces a value range below the possible physical storage range. /Oskar

What if the compiler wouldn't enforce the value to be 0 or 1 in bool.init? This way the initial value could be 0xFF indicating that a variable is not initialized by the user.
Aug 15 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lionello Lunesu wrote:

 I've been following those "why's char init'ed to -1?" / "why's float 
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
 initialization sure makes it obvious where the problem lies.

I'm not sure that "more crazy .init values" is the cure to char/float... --anders
Aug 15 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Anders F Björklund wrote:
 Lionello Lunesu wrote:
 
 I've been following those "why's char init'ed to -1?" / "why's float 
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
 initialization sure makes it obvious where the problem lies.

I'm not sure that "more crazy .init values" is the cure to char/float...

Well, it would have helped me find a very old bug (a bool that wasn't inited). L.
Aug 15 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lionello Lunesu wrote:

 I'm not sure that "more crazy .init values" is the cure to char/float...

Well, it would have helped me find a very old bug (a bool that wasn't inited).

I'm glad that they help you all find bugs, I guess I'm just too old and used to zero-as-initializer to get used to the D initializers... Nothing to worry about. Maybe I will see the light, and like them ? Glad the age-old bug with the array initializers* was fixed, though. --anders * i.e. the one where they were getting all zeroes, instead of .init
Aug 15 2006
prev sibling next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Lionello Lunesu wrote:
 I've been following those "why's char init'ed to -1?" / "why's float 
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
 initialization sure makes it obvious where the problem lies.
 
 So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, bool.init 
 is 0, which is a valid value for bool. For byte/int/long I get it, since 
 there is no invalid value for byte/int/long. But for bool there is, so 
 the same reasoning as char/float applies.
 
 We could even name 0xFF "Not A Bool" ;)
 
 L.

void main() { bool b; // b is 0xFF if (b) { // Is b true or false? // ... } } -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.org
Aug 15 2006
parent Lionello Lunesu <lio lunesu.remove.com> writes:
Kirk McDonald wrote:
 Lionello Lunesu wrote:
 I've been following those "why's char init'ed to -1?" / "why's float 
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
 initialization sure makes it obvious where the problem lies.

 So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, bool.init 
 is 0, which is a valid value for bool. For byte/int/long I get it, 
 since there is no invalid value for byte/int/long. But for bool there 
 is, so the same reasoning as char/float applies.

 We could even name 0xFF "Not A Bool" ;)

 L.

void main() { bool b; // b is 0xFF if (b) { // Is b true or false? // ... } }

void main() { bool b; // b is 0x00 if (b) { // Is b true or false? // ... } } L.
Aug 16 2006
prev sibling next sibling parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
That make only problems, nothing more.
I don't like this suggestion.

VOTE--;
Aug 16 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Frank Benoit wrote:
 That make only problems, nothing more.
 I don't like this suggestion.
 
 VOTE--;

Frankly, it's not about liking or not. This suggestion is about consistency. I think the same reasons for the 0xFF initializer for char/wchar/dchar also apply to bool. L.
Aug 16 2006
parent Max Samuha <maxter i.com.ua> writes:
On Wed, 16 Aug 2006 14:45:57 +0300, Lionello Lunesu
<lio lunesu.remove.com> wrote:

Frank Benoit wrote:
 That make only problems, nothing more.
 I don't like this suggestion.
 
 VOTE--;

Frankly, it's not about liking or not. This suggestion is about consistency. I think the same reasons for the 0xFF initializer for char/wchar/dchar also apply to bool. L.

For consistency, I'd personally prefer what they call 'nullable value types' in C#. If you want to distinguish between initialized and null variables of value type just add ? to the type identifier. I know that such types require more memory to store additional information about the null state but the approach is much nicer and consistent than special value hacks (imho). bool? b = null; if (b == null){} Oops, i forget that D is not C#:)
Aug 16 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Lionello Lunesu wrote:
 I've been following those "why's char init'ed to -1?" / "why's float 
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
 initialization sure makes it obvious where the problem lies.
 
 So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, bool.init 
 is 0, which is a valid value for bool. For byte/int/long I get it, since 
 there is no invalid value for byte/int/long. But for bool there is, so 
 the same reasoning as char/float applies.
 
 We could even name 0xFF "Not A Bool" ;)
 
 L.

You are right that it would be more consistent to have a "Not a Bool" value. But this should not be implemented because of performance implications: It would slow down conversions from int to bool, as well as any kind of bool access/use, where a check for Not A Bool would have to be made (and an exception thrown when necessary). b1 == b2 // has to check if b1 or b2 is NotABool if(b1) // has to check if b1 is NotABool -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 16 2006
parent Lionello Lunesu <lio lunesu.remove.com> writes:
Bruno Medeiros wrote:
 Lionello Lunesu wrote:
 I've been following those "why's char init'ed to -1?" / "why's float 
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
 initialization sure makes it obvious where the problem lies.

 So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, bool.init 
 is 0, which is a valid value for bool. For byte/int/long I get it, 
 since there is no invalid value for byte/int/long. But for bool there 
 is, so the same reasoning as char/float applies.

 We could even name 0xFF "Not A Bool" ;)

 L.

You are right that it would be more consistent to have a "Not a Bool" value. But this should not be implemented because of performance implications: It would slow down conversions from int to bool, as well as any kind of bool access/use, where a check for Not A Bool would have to be made (and an exception thrown when necessary). b1 == b2 // has to check if b1 or b2 is NotABool if(b1) // has to check if b1 is NotABool

Actually, you've raised an interesting point! Just as float NaN is not equal to anything, a 0xFF bool would neither be false, nor true. I don't think that anything else is needed besides the changed initializer. Float NaNs are not being checked anywhere. They just sit there until they're overwritten, or they appear (in output or debugger) and then you'll know that something is wrong. Of course, there could be an option to make sure that a bool is either true or false, but I don't see this as a necessary implication of the original suggestion. L.
Aug 16 2006
prev sibling parent reply nobody <nobody mailinator.com> writes:
Lionello Lunesu wrote:
 I've been following those "why's char init'ed to -1?" / "why's float 
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
 initialization sure makes it obvious where the problem lies.
 
 So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, bool.init 
 is 0, which is a valid value for bool. For byte/int/long I get it, since 
 there is no invalid value for byte/int/long. But for bool there is, so 
 the same reasoning as char/float applies.
 
 We could even name 0xFF "Not A Bool" ;)
 
 L.

I understand why this idea might seem appealing but I am fairly certain it is ultimately a bad idea. The two examples you gave are different from bool. In the case of the reals the reason so much care is taken to assure NaNs propogate freely is because (unlike any other basic type) the result of almost any real valued operation which has valid arguments may not be representable as a real number. Using NaN as a default initializer is merely an elegant side effect. NaNs require special treatment however. In particular note: if( NaN <= 0 ) // always fails if( NaN >= 0 ) // also always fails Obviously the elegance of NaN as an initializer prompted the realization that 0xFF is illegal for any ubyte value in a UTF-8 encoded string. Because any invalid UTF-8 encoded string should be caught when it is used it is likely to assume an invalid encoding would raise an Exception somewhere. There is a subtle distinction between NaN and 0xFF. 0xFF by itself does not represent an entire invalid sequence. A valid sequence can have use up to 4 bytes to encode a single Unicode code point. Other values in various positions can also invalidate a sequence. 0xC0, 0xC1, 0xF5 and 0xFF are all invalid in any position. In contrast to the semantics of NaN, in particular note: if(0xF5) // always succeeds if(0xFF) // always succeeds if(0xFF >= 0) // always succeeds The biggest problem with your suggestion is the existing semantics of conditions would mean just changing the initializer would not ordinarily indicate a problem when using a bool value: http://www.digitalmars.com/d/statement.html#if /Expression/ is evaluated and must have a type that can be converted to a boolean. If it's true the /ThenStatement/ is transferred to, else the /ElseStatement/ is transferred to. So the 'undefined' bool value 0xFF will be converted just like a char or ubyte and will evaluate as true! Certainly this behavior is even worse than having a default of false? One might imagine it should be possible to change the way if expressions work. Except you would also have to change the equivalent for, foreach and while conditionals as well. The worst part is that the general case of conditional expressions are in fact testing relations on non-bool values -- so most of the time you will be testing to see if you should throw an Exception for bool's 'undefined' value in cases where it is not even possible. A further problem I see comes from my (possibly wrong?) belief that bit[] has become bool[]. If bool[32] occupies 4 bytes as I believe then in this case there is no room for bool's 'undefined'. So then one must ask what value should be bools default in this case?
Aug 16 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
nobody wrote:
 Lionello Lunesu wrote:
 I've been following those "why's char init'ed to -1?" / "why's float 
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
 initialization sure makes it obvious where the problem lies.

 So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, bool.init 
 is 0, which is a valid value for bool. For byte/int/long I get it, 
 since there is no invalid value for byte/int/long. But for bool there 
 is, so the same reasoning as char/float applies.

 We could even name 0xFF "Not A Bool" ;)

 L.

I understand why this idea might seem appealing but I am fairly certain it is ultimately a bad idea. The two examples you gave are different from bool. In the case of the reals the reason so much care is taken to assure NaNs propogate freely is because (unlike any other basic type) the result of almost any real valued operation which has valid arguments may not be representable as a real number. Using NaN as a default initializer is merely an elegant side effect. NaNs require special treatment however.

The propogation of NaNs is indeed a nice feature, and it might be nice to note that operator | propogates 0xFF-bools in a similar fashion (& does not, though, and ^ can result in yet another invalid boolean value).
 So the 'undefined' bool value 0xFF will be converted just like a char or 
 ubyte and will evaluate as true! Certainly this behavior is even worse 
 than having a default of false?

This I don't get. How's having a default of false better than having a default of true?
 One might imagine it should be possible to change the way if expressions 
 work. Except you would also have to change the equivalent for, foreach 
 and while conditionals as well. The worst part is that the general case 
 of conditional expressions are in fact testing relations on non-bool 
 values -- so most of the time you will be testing to see if you should 
 throw an Exception for bool's 'undefined' value in cases where it is not 
 even possible.

I don't see checking for invalid boolean values as a necessity, let alone throwing an exception. Look at NaNs. Yes, they propogate, and if after a lengthy calculation you print the output and you see that you end up with a NaN, you know that you've used a NaN along the way. But how often do you print the output of such a calculation? Surely most of the time the numbers are simply used somewhere, a position of an object, the color of a pixel, or simply a comparison "if (f<0.4)...". How does a NaN show up in those situations? Not as a nicely printed "NaN", that's for sure. The power of the funky default initializer lies in the debugging, not in it's 'default behavior'. Yes, it's _handy_ to have bools initialized to false, since that's a useful value. It'll save you typing. But it's an arbitrary choice. In 50% of the cases you'll want an initializer of 'false', and in the other 50% you'll want 'true'. In the first cases you don't type anything (since the default is false, handy) and in the latter cases you'll have to implicitly type the "= true".
 A further problem I see comes from my (possibly wrong?) belief that 
 bit[] has become bool[]. If bool[32] occupies 4 bytes as I believe then 
 in this case there is no room for bool's 'undefined'. So then one must 
 ask what value should be bools default in this case?

bit is gone, and bool is similar to C++'s bool. bool.sizeof==1, and a bool[32] needs 32 bytes. How about this for consistency: similar to the floating point comparisons, the operators <>, !<>, <>=, !<>= could be used to check for "not a bool"? (don't ask me how exactly; I don't quite grasp the <> yet.) L.
Aug 17 2006
parent reply nobody <nobody mailinator.com> writes:
Lionello Lunesu wrote:
 nobody wrote:
 Lionello Lunesu wrote:
 I've been following those "why's char init'ed to -1?" / "why's float 
 init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
 initialization sure makes it obvious where the problem lies.

 So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, 
 bool.init is 0, which is a valid value for bool. For byte/int/long I 
 get it, since there is no invalid value for byte/int/long. But for 
 bool there is, so the same reasoning as char/float applies.

 We could even name 0xFF "Not A Bool" ;)

 L.

I understand why this idea might seem appealing but I am fairly certain it is ultimately a bad idea. The two examples you gave are different from bool. In the case of the reals the reason so much care is taken to assure NaNs propogate freely is because (unlike any other basic type) the result of almost any real valued operation which has valid arguments may not be representable as a real number. Using NaN as a default initializer is merely an elegant side effect. NaNs require special treatment however.

The propogation of NaNs is indeed a nice feature, and it might be nice to note that operator | propogates 0xFF-bools in a similar fashion (& does not, though, and ^ can result in yet another invalid boolean value).
 So the 'undefined' bool value 0xFF will be converted just like a char 
 or ubyte and will evaluate as true! Certainly this behavior is even 
 worse than having a default of false?

This I don't get. How's having a default of false better than having a default of true?

I can see why this might not be obvious if you do not much of a background with C style languages. In most C style languages (C, C++, Java and D) pretty much anything is 'true' if it is non-zero because 'truth' can be determined by simply testing for inequality with the constant 0. Thus the only default initializer which works the same for "pretty much anything" is a zero bit pattern. I think it is impossible to stress enough how ingrained this reality becomes. The best example of exactly how ingrained it is would be my implicit assumption that anyone else would see the folly of a default value evaluating true.
 
 One might imagine it should be possible to change the way if 
 expressions work. Except you would also have to change the equivalent 
 for, foreach and while conditionals as well. The worst part is that 
 the general case of conditional expressions are in fact testing 
 relations on non-bool values -- so most of the time you will be 
 testing to see if you should throw an Exception for bool's 'undefined' 
 value in cases where it is not even possible.

I don't see checking for invalid boolean values as a necessity, let alone throwing an exception. ... The power of the funky default initializer lies in the debugging, not in it's 'default behavior'. Yes, it's _handy_ to have bools initialized to false, since that's a useful value. It'll save you typing. But it's an arbitrary choice. In 50% of the cases you'll want an initializer of 'false', and in the other 50% you'll want 'true'. In the first cases you don't type anything (since the default is false, handy) and in the latter cases you'll have to implicitly type the "= true".

Again this runs deeper than just typing one random thing instead of another. It is about a deeply ingrained way of looking at the world. Your 50% figure is based on the assumption of random distribution which may seem close enough to true for you. In the case of people coming to D from other C style languages the figure is probably very close to 100% of case wanting false.
 A further problem I see comes from my (possibly wrong?) belief that 
 bit[] has become bool[]. If bool[32] occupies 4 bytes as I believe 
 then in this case there is no room for bool's 'undefined'. So then one 
 must ask what value should be bools default in this case?

bit is gone, and bool is similar to C++'s bool. bool.sizeof==1, and a bool[32] needs 32 bytes.

Do you know why it was eliminated? Or perhaps have some idea of when? Or even a general spot to start looking in posts to find out why myself?
Aug 17 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
 This I don't get. How's having a default of false better than having a 
 default of true?

I can see why this might not be obvious if you do not much of a background with C style languages. In most C style languages (C, C++, Java and D) pretty much anything is 'true' if it is non-zero because 'truth' can be determined by simply testing for inequality with the constant 0. Thus the only default initializer which works the same for "pretty much anything" is a zero bit pattern. I think it is impossible to stress enough how ingrained this reality becomes. The best example of exactly how ingrained it is would be my implicit assumption that anyone else would see the folly of a default value evaluating true.

I'm coming from C/C++ myself. In C/C++ you always have to initialize your variables, so the language has no preference for either true or false. Are you saying that you name your variables and flags such that "false" is the default? That seems like strange to me. For program options, for example, it would mean that you choose names that are "not true" (options that are not selected) as the default. Seems exactly the wrong way around. Not to mention the fact that you can end up with variables called "NotShowingSizes = false;" and "if (!NotShowingSizes) ..." :S
     bit is gone, and bool is similar to C++'s bool. bool.sizeof==1, 
 and a bool[32] needs 32 bytes.

Do you know why it was eliminated? Or perhaps have some idea of when? Or even a general spot to start looking in posts to find out why myself?

I think because of the problems with bit[] and the fact that you could not take a pointer to it. Check the change log http://www.digitalmars.com/d/changelog.html (I would check it for you, but it seems I can't access it at the moment?) L.
Aug 18 2006
parent nobody <nobody mailinator.com> writes:
Lionello Lunesu wrote:
 This I don't get. How's having a default of false better than having 
 a default of true?

I can see why this might not be obvious if you do not much of a background with C style languages. In most C style languages (C, C++, Java and D) pretty much anything is 'true' if it is non-zero because 'truth' can be determined by simply testing for inequality with the constant 0. Thus the only default initializer which works the same for "pretty much anything" is a zero bit pattern. I think it is impossible to stress enough how ingrained this reality becomes. The best example of exactly how ingrained it is would be my implicit assumption that anyone else would see the folly of a default value evaluating true.

I'm coming from C/C++ myself. In C/C++ you always have to initialize your variables, so the language has no preference for either true or false. Are you saying that you name your variables and flags such that "false" is the default? That seems like strange to me. For program options, for example, it would mean that you choose names that are "not true" (options that are not selected) as the default. Seems exactly the wrong way around. Not to mention the fact that you can end up with variables called "NotShowingSizes = false;" and "if (!NotShowingSizes) ...." :S

HideSizes (gerunds don't work for me here) : )
 
     bit is gone, and bool is similar to C++'s bool. bool.sizeof==1, 
 and a bool[32] needs 32 bytes.

Do you know why it was eliminated? Or perhaps have some idea of when? Or even a general spot to start looking in posts to find out why myself?

I think because of the problems with bit[] and the fact that you could not take a pointer to it. Check the change log http://www.digitalmars.com/d/changelog.html (I would check it for you, but it seems I can't access it at the moment?)

Thanks for the suggestion. I will probably have to kill my thunderbird NG subscription and try loading up 5,000 archived messages to see if that gets me back to the reasoning behind the Feb changes. http://www.digitalmars.com/d/changelog.html What's New for D 0.148 Feb 25, 2006 New/Changed Features ... # Removed bit basic type. # Added bool basic type. # Added BitArray.
Aug 18 2006