Operator overloading, structs

[Yigal Chripun]

dsimcha wrote:
> == Quote from bearophile (bearophileHUGS at lycos.com)'s article
>> Yigal Chripun:
>>> why not just use (i != 0) in both cases?
>> Yes, here it can be done (if Don has implemented opEquals(int y)), 
>> but you don't
> need that once you have something like opBool.
>>> conversion of ints to bools in C is IMO a hole in the type system
>>>  due to the lack of a boolean type in C. All those narrowing 
>>> implicit casts inherited from C are a bad idea IMO.
>> Walter was right, converting a generic integral to bool requires 
>> some time, that
> in the middle of the the nested loop can slow down code a bit (5%, in
>  a case of mine).
>> A standard opBool method allows you to tell when a collection is 
>> empty, like an
> empty string, an empty range, an empty array, and so on. you can use 
> it instead of somecollection.isEmpty().
>> Java as Pascal keep booleans and integers separated, this looks 
>> tidy and clean.
> I love clean things, but in practice I don't think the current design
>  of D (and C, Python, and several other languages) leads to a 
> significant amount of bugs. It seems one of those situations where 
> practical considerations win over purity.
> 
> For D and other close to the metal languages, IMHO the int-bool 
> relationship should stay the way it is simply because that's the way 
> it works on the bare metal (at least on x86, for example, 
> instructions like jz).  I think this is a good rule of thumb in a 
> close to the metal language, and even in the general case:  When in 
> doubt, do the thing that gives the user the least obstructed view of 
> how things "really" work at the next lower level.  This avoids lots 
> of silly abstraction inversions (One of which is building a strong 
> boolean type on top of an int).
> 

close to the metal does not imply in any way you code with binary
op-codes or assembly concepts. all it means is that it does not force 
upon you costly abstractions and mechanisms like a VM. this does not 
apply to this discussion since a bool type doesn't require a VM and does 
not penalize performance in any way.

your abstraction inversion example doesn't apply here. The problem I see 
is the narrowing implicit cast, i.e. int values behave like booleans. I 
have no problem with the reverse which is what your example is about.