That make only problems, nothing more.
I don't like this suggestion.

VOTE--;

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.

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

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#:)

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.

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?

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.

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?

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

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.