digitalmars.D - Shouldn't bool be initialized to 0xFF ?
- Lionello Lunesu (9/9) Aug 15 2006 I've been following those "why's char init'ed to -1?" / "why's float
- Oskar Linde (10/20) Aug 15 2006 There is a difference here. For char, 0xff is a valid value. That is,
- Kristian Kilpi (5/23) Aug 15 2006 What if the compiler wouldn't enforce the value to be 0 or 1 in bool.ini...
- Lionello Lunesu (9/29) Aug 15 2006 For float, I'd have to agree with you.
- Kristian Kilpi (5/23) Aug 15 2006 What if the compiler wouldn't enforce the value to be 0 or 1 in bool.ini...
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (3/6) Aug 15 2006 I'm not sure that "more crazy .init values" is the cure to char/float...
- Lionello Lunesu (4/11) Aug 15 2006 Well, it would have helped me find a very old bug (a bool that wasn't
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (7/11) Aug 15 2006 I'm glad that they help you all find bugs, I guess I'm just too old
- Kirk McDonald (11/23) Aug 15 2006 void main() {
- Lionello Lunesu (8/29) Aug 16 2006 void main() {
- Frank Benoit (3/3) Aug 16 2006 That make only problems, nothing more.
- Lionello Lunesu (5/9) Aug 16 2006 Frankly, it's not about liking or not. This suggestion is about
- Max Samuha (11/20) Aug 16 2006 For consistency, I'd personally prefer what they call 'nullable value
- Bruno Medeiros (11/23) Aug 16 2006 You are right that it would be more consistent to have a "Not a Bool"
- Lionello Lunesu (12/33) Aug 16 2006 Actually, you've raised an interesting point!
- nobody (43/55) Aug 16 2006 I understand why this idea might seem appealing but I am fairly certain ...
- Lionello Lunesu (29/67) Aug 17 2006 The propogation of NaNs is indeed a nice feature, and it might be nice
- nobody (16/81) Aug 17 2006 I can see why this might not be obvious if you do not much of a backgrou...
- Lionello Lunesu (14/31) Aug 18 2006 I'm coming from C/C++ myself. In C/C++ you always have to initialize
- nobody (13/47) Aug 18 2006 Thanks for the suggestion. I will probably have to kill my thunderbird N...
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
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
"Kristian Kilpi" <kjkilpi gmail.com> On Tue, 15 Aug 2006 17:09:16 +0300, Oskar Linde <oskar.lindeREM OVEgmail.com> wrote:Lionello Lunesu wrote: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.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
Oskar Linde wrote:Lionello Lunesu wrote: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.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.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
On Tue, 15 Aug 2006 17:09:16 +0300, Oskar Linde <oskar.lindeREM OVEgmail.com> wrote:Lionello Lunesu wrote: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.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
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
Anders F Björklund wrote:Lionello Lunesu wrote:Well, it would have helped me find a very old bug (a bool that wasn't inited). L.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...
Aug 15 2006
Lionello Lunesu wrote: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 .initI'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).
Aug 15 2006
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
Kirk McDonald wrote:Lionello Lunesu wrote:void main() { bool b; // b is 0x00 if (b) { // Is b true or false? // ... } } L.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? // ... } }
Aug 16 2006
That make only problems, nothing more. I don't like this suggestion. VOTE--;
Aug 16 2006
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
On Wed, 16 Aug 2006 14:45:57 +0300, Lionello Lunesu <lio lunesu.remove.com> wrote:Frank Benoit wrote:For consistency, I'd personally prefer what they call 'nullable value 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){}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
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
Bruno Medeiros wrote:Lionello Lunesu wrote: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.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
Aug 16 2006
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
nobody wrote:Lionello Lunesu wrote: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).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.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
Lionello Lunesu wrote:nobody wrote: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.Lionello Lunesu wrote: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).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.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?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.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".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?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.
Aug 17 2006
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) ..." :SThis 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 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.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 18 2006
Lionello Lunesu wrote:HideSizes (gerunds don't work for me here) : )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) ...." :SThis 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.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 ...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?)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 18 2006