I give in. I'm doing the decent thing and returning "bool" everythere instead of "Bool" - not because I think Walter's got it right, but because conflicting standards are no good for anyone. I really *do* believe that, one day in the future, when standards committees define what D should or should not do, "bool" itself will be made typesafe, and that transition will of course be easier if we all (or at least, all public APIs) use the same keyword.

Currently, however, there will have to be one exception (bah!). The exception is
opEquals(), which is defined in object.d to return an int. This is still BAD ...
as Daniel Horn discovered the other day. It seems that on Linux, == sometimes
returns a value other than 0 or 1. This could never have happened if opEquals
had been defined to return (Walter's) bool (that is, aliased to bit).

Please, please, please could opEquals() return bool, not int, for all objects. Now we are seeing platform-dependent behavior because of this. It really should be fixed. I can't imagine why opEquals() would want to return an int. I'm assuming it was a mistake, but Walter, if there's a good reason for it, please could you clarify for me what that reason is?

Arcane Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9p65n$2e8e$1@digitaldaemon.com...
> Please, please, please could opEquals() return bool, not int, for all
objects.
> Now we are seeing platform-dependent behavior because of this. It really
should
> be fixed. I can't imagine why opEquals() would want to return an int. I'm assuming it was a mistake, but Walter, if there's a good reason for it,
please
> could you clarify for me what that reason is?

The reason is runtime efficiency, as described in my reply to your posting "Efficiency test for various boolean strategies." opEquals() has the potential to be a huge performance bottleneck for sorting and searching algorithms, so defining it so it can be implemented as efficiently as possible is important.

Tell me, if n is an int, what does (cast(bool)n) do, exactly?

Does it do (n & 1), in the same way that (cast(ubyte)n) does (n & 0xFF)? Or does
it do (n==0 ? 0 : 1). In other words, does it truncate like ints, or saturate
like floats?

I haven't seen a definition anywhere, and if opEquals() is allowed to return
non-0, non-1 values (even by accident) it would be useful to know that casting
to bool is always going to do the right thing.

Jill

In article <c9p965$2kcb$1@digitaldaemon.com>, Arcane Jill says...

>I haven't seen a definition anywhere, and if opEquals() is allowed to return
>non-0, non-1 values (even by accident) it would be useful to know that casting
>to bool is always going to do the right thing.

Casting integer to bool returns false for 0, otherwise it returns true, to be consistent with C semantics. Same convention applies when short-cut operators are executed on integers.

-eye

Walter schrieb:

>>be fixed. I can't imagine why opEquals() would want to return an int. I'm
>>assuming it was a mistake, but Walter, if there's a good reason for it, please
>>could you clarify for me what that reason is?
> 
> 
> The reason is runtime efficiency, as described in my reply to your posting
> "Efficiency test for various boolean strategies." opEquals() has the
> potential to be a huge performance bottleneck for sorting and searching
> algorithms, so defining it so it can be implemented as efficiently as
> possible is important.

Is there any chance that you change that to bit, and make a compiler provosion that would e.g. always hand bit as int when it is used as a return value to a back end? Perhaps bit should always be stored in an int storage instead of a byte storage, except for within structs and as bit arrays, where multiple adjacent bits would complement each other to bytes? Wasn't it your argumentation that code should follow principles of expressiveness, and it's compiler's work to take care of efficiency?

I'm not sure where the storage size becomes relevant to performance. If i remember correctly from fog's pentopt, on modern processors mostly alignment is important. Is there anything else causing the penalty?

-eye

Ilya Minkov wrote:

> Walter schrieb:
>
>>> be fixed. I can't imagine why opEquals() would want to return an int. I'm
>>> assuming it was a mistake, but Walter, if there's a good reason for it, please
>>> could you clarify for me what that reason is?
>>
>>
>>
>> The reason is runtime efficiency, as described in my reply to your posting
>> "Efficiency test for various boolean strategies." opEquals() has the
>> potential to be a huge performance bottleneck for sorting and searching
>> algorithms, so defining it so it can be implemented as efficiently as
>> possible is important.
>
>
> Is there any chance that you change that to bit, and make a compiler provosion that would e.g. always hand bit as int when it is used as a return value to a back end? Perhaps bit should always be stored in an int storage instead of a byte storage, except for within structs and as bit arrays, where multiple adjacent bits would complement each other to bytes?

I'd make that
except for within structs, multiple function parameters and as bit arrays,

I guess the way bit is defined now makes it possible for D vendors to optimise it however they want.  Of couse dmd is the major D vendor at the moment and I would hope that dmd will one day include these types of optimisations.

I think the more details you provide to the compiler about what you are doing the better it should be able to optimise your code.  If you only need a bit, you should use a bit and the compiler should worry about making optimisations on that type.  Since the compiler knows that a bit will only ever be on or off, then it should be able to use that to its advantage, not to its determent.

-- 
-Anderson: http://badmama.com.au/~anderson/

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9p965$2kcb$1@digitaldaemon.com...
>
> Tell me, if n is an int, what does (cast(bool)n) do, exactly?

n?1:0

Walter wrote:

> 
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9p965$2kcb$1@digitaldaemon.com...
>>
>> Tell me, if n is an int, what does (cast(bool)n) do, exactly?
> 
> n?1:0

Now, this seems like a language inconsistency to me: if bit is supposed to be an integer type of length one bit, then it should actually cast like the other integer types, i.e. by masking the original value.

if
        (cast(ubyte)n) == (n & 0xff)
then I would expect
        (cast(bit)n) == (n & 0x01)

Of course, this would have little practical use. Oh, well - guess that's just once again the good old thing about bool vs. bit... :-)

FWIW, I totally changed my stance on the "bool" issue this morning.  I realized my complaints were all due to semantics.  To me, "bool" purely describes behavior, and I've been basing my expectations based on my experience with C/C++.  "bit," however, is a far more descriptive term.  It describes both behavior and storage, and is far more clear to me than "bool."  Simply put, I have no issues at all with the current behavior of the bit datatype.  But if I had my druthers we'd just do away with the bool alias and make a clean break with the past... which probably puts me in the minority on this list :)

I do think that Phobos should document its interfaces using "bit" however. Mixing both terms seems inconsistent and slightly confusing to newcomers, and invites problems on the off chance that the definition of "bool" ever changes.

Sean

Sean Kelly wrote:
> FWIW, I totally changed my stance on the "bool" issue this morning.  I realized
> my complaints were all due to semantics.  To me, "bool" purely describes
> behavior, and I've been basing my expectations based on my experience with
> C/C++.  "bit," however, is a far more descriptive term.  It describes both
> behavior and storage, and is far more clear to me than "bool."  Simply put, I
> have no issues at all with the current behavior of the bit datatype.  But if I
> had my druthers we'd just do away with the bool alias and make a clean break
> with the past... which probably puts me in the minority on this list :)
> 
> I do think that Phobos should document its interfaces using "bit" however.
> Mixing both terms seems inconsistent and slightly confusing to newcomers, and
> invites problems on the off chance that the definition of "bool" ever changes.
> 
> Sean

I also fail to see the advantage of the bool alias. It seems inconsistent with the separation of language and library. Since bit is part of the language, why should we need to call the same thing "bool"? Perhaps bit is a naughty word in someone's culture, but it seems like an invitation to confusion to hide a subtle alias in object.d. (Of course, I'm also in favor of removing printf/wprintf from object.d.)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/