Operator overloading, structs

[Yigal Chripun]

bearophile wrote:
> 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. There are other situations where I'd like to see fixed some
> implicit type conversions. C# shows a saner design in such regard.
> There are few things in C# that I'd like to see copied by D.
> 
if I understand you correctly, you claim that the C behavior is just 
more practical and/or useful than the Pascal approach. this is where we 
differ. The _only_ practical benefit I see is that it saves you two 
characters to type. on the other hand you get less readable code which 
can potentially be buggy.
it's not important that the chance to get a bug here for an experienced 
C programmer (or a Python one) is slim since the comparison is against 
absolute zero chance of bugs with the pure approach. any small positive 
epsilon is still greater than zero.

> 
>> the need to convert the bigInt to long in order to print it is a
>> design error in printf() - the format string should specify the
>> formatting of the variables not their types.
> 
> printf was invented lot of time ago, in galaxy far away, when needs
> and situations were different. That code of mine is wrong, this is
> more correct, so here it's not printf fault: 
> printf("%d\n", a[to!(long)i]); 
 > Because it's "i" the BigInt, not the contents of the
> "a" array.
> 
> Bye, bearophile