In article <df5986$2k8h$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <1vyjlspt3ayjp.i722adx36thy.dlg@40tude.net>, Derek Parnell says...
>>
>>On Wed, 31 Aug 2005 14:13:42 +0000 (UTC), Shammah Chancellor wrote:
>>
>>> Is truth the complement of falsehood?   Who defines truth as anything which is not false?
>>
>>Ummm... me?  I kinda feel that an assertion is either true or false but not both at the same time. It cannot be neither, although we may not know which it is at any given instant.  But now we getting all philosophical and off topic ;-)
>
>Quantum states make things even more intersting ;-)  The answer to this seems to go back to the old argument about whether bit is a numeric or logical type.  If bit is numeric then current behavior makes perfect sense, but the constants 'true' and 'false' are quite misleading.  Otherwise, I agree that the behavior must change.
>
>
>Sean

Bit is a numeric type, bool is a logical type.  Bool should be seperate as
another thread was arguing.
The behavior of bit should not be changed.

Also, I find it funny that the person who posted this:

Nothing, except that ends() return an integer (-1) if it fails, and the
compiler doesn't bother to mention that it's implicitly converting the bool
(true) to an integer. Not even if -w is operating.

Is now posting this:

Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'?

<snip>
if (A) writefln("A");
if (A!=0) writefln("A!=0");
if (A==true) writefln("A==true");
<snip>

Why are you, who seemed to be opposed of conversions from ints to bool (which i
agree with.) now
upset that A==true returns false when A is the integer 2?????????!?!?!?!?!
According to your previous
statements it should throw an exception or be a compiler error!!!

Not to mention the whole proposition is silly considering MOST of the time when
you're checking for
trueness or falseness against an integer, ZERO is true, and anything else
represents how false the
comparision is.

IE:  strcmp() == false <-- would return true when strcmp is true, this code is
wrong.
strcmp() == true <-- returns true when strcmp happens to return 1, the strings
are unequal. still
wrong code.  Even with == true being rewritten as != 0 being "truth" this would
still give the wrong
answer.

-Sha

On Thu, 1 Sep 2005 00:23:32 +0000 (UTC), Shammah CHancellor wrote:

> In article <df5986$2k8h$1@digitaldaemon.com>, Sean Kelly says...
>>
>>In article <1vyjlspt3ayjp.i722adx36thy.dlg@40tude.net>, Derek Parnell says...
>>>
>>>On Wed, 31 Aug 2005 14:13:42 +0000 (UTC), Shammah Chancellor wrote:
>>>
>>>> Is truth the complement of falsehood?   Who defines truth as anything which is not false?
>>>
>>>Ummm... me?  I kinda feel that an assertion is either true or false but not both at the same time. It cannot be neither, although we may not know which it is at any given instant.  But now we getting all philosophical and off topic ;-)
>>
>>Quantum states make things even more intersting ;-)  The answer to this seems to go back to the old argument about whether bit is a numeric or logical type.  If bit is numeric then current behavior makes perfect sense, but the constants 'true' and 'false' are quite misleading.  Otherwise, I agree that the behavior must change.
>>
>>
>>Sean
> 
> Bit is a numeric type, bool is a logical type.  Bool should be seperate as
> another thread was arguing.
> The behavior of bit should not be changed.

In theory, I totally, 110%, agree with that position.

> Also, I find it funny that the person who posted this:
>
> Nothing, except that ends() return an integer (-1) if it fails, and the
> compiler doesn't bother to mention that it's implicitly converting the bool
> (true) to an integer. Not even if -w is operating.

But in practice, nothing is ever going to change Walters mind, so I'm
trying to go with the flow (and just between you and me, maybe we can sneak
up on Walter and change his stance by stealth; but keep that a secret,
okay?) and thus minimize wasted efforts.

> Is now posting this:
> 
> Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'?

It's called "waiting for the right time to pick a fight" ;-)

> Why are you, who seemed to be opposed of conversions from ints to bool (which i
> agree with.) now
> upset that A==true returns false when A is the integer 2?????????!?!?!?!?!
> According to your previous
> statements it should throw an exception or be a compiler error!!!

But occasionally I'm a practical person. So I'm letting this one slip by
and asking for it in a different (and admittedly piecemeal) way.

> Not to mention the whole proposition is silly considering MOST of the time when
> you're checking for
> trueness or falseness against an integer, ZERO is true, and anything else
> represents how false the
> comparision is.
> 
> IE:  strcmp() == false <-- would return true when strcmp is true, this code is
> wrong.
> strcmp() == true <-- returns true when strcmp happens to return 1, the strings
> are unequal. still
> wrong code.  Even with == true being rewritten as != 0 being "truth" this would
> still give the wrong
> answer.

But the function isn't named "isstrequal" so I'm not expecting an either/or return value. From my assembler experience, I'm quite used to the cmp instruction and then testing for any number of results; jeq, jne, jgt, jlt, jge, jle.

If we had a function called "isequal(char[] A, char[] B)" then I would expect that function to return a yes/no response. That's why I took our colleague's advice and changed my 'ends()' function to return a yes/no value - because it reads better that way.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
1/09/2005 10:26:32 AM

Shammah CHancellor wrote:

> Bit is a numeric type, bool is a logical type.
> Bool should be seperate as another thread was arguing.  The behavior of bit should not be changed.

* me wakes up, wonder if anything happened to D *
- "oh no, not that same old tired discussion again"
* goes back to sleep, dreaming of something else *

--anders

PS.
Here was my old attempt to make lemonade out of it:
http://www.prowiki.org/wiki4d/wiki.cgi?BitsAndBools

"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:df5gjh$2rbk$1@digitaldaemon.com...
> In article <1xfwna3ygghr4.vv7m5z2cm8rt.dlg@40tude.net>, Derek Parnell says...
>>
>>On Wed, 31 Aug 2005 14:46:29 -0400, Ben Hinkle wrote:
>>
>>> "Derek Parnell" <derek@psych.ward> wrote in message news:jag0mz602hw$.u59i5vti46wf$.dlg@40tude.net...
>>>> Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'?
>>>
>>> Or one could change the implicit conversion rules "usual arithmetic
>>> conversions" described on http://www.digitalmars.com/d/type.html to say
>>> that
>>> if one of the two types is "bit" that the other type is converted to
>>> bit.
>>> This would be rule 4a - between the float conversions and the integer
>>> promotions. Then <expr> == true would have the behavior you expect.
>>
>>Yep, that would do it too.
>
> This is rediculous.  Bit should be consistent with int and any other
> numeric
> type.  Bool should be a
> separate type as another thread was stating.

Search the newsgroups for bit vs bool related threads to get the background on bits and bools. It was a hot topic a while ago but hasn't flared up lately.

> Converting any other type to bit when the number is
> greater than 1 would not result in the expected behavior, but instead an
> overflow. It should throw an exception.

Throwing an exception on a numeric conversion would be bad. Converting integer values x that != 0 to true is the desired behavior since it then matches the expression x?true:false.

> Why would a comparision for bit demote the larger type? Everywhere else
> where
> numbers are promoted!
> (To prevent overflows when comparing long to int!)

The only useful binary ops involving bit and some other integer type are things that result in bits. Wacky code that really wants bits treated like the ints 0 and 1 (like x*flag for a bit valued flag) can cast the bit to an int. The mental model of integer ranges like int, long etc does not apply to bits since there's only two values 0/1 not a range of values like 0 to 255 and no-one should be doing range-based arithmetic on bits.