unsigned policy

[Sean Kelly]

Andrei Alexandrescu (See Website For Email) wrote:
> Henning Hasemann wrote:
>> I know this is a more general questions as it applies to C and C++ as 
>> well,
>> but somewhere I have to ask and actually D is what Im coding in:
>>
>> Should one try to use uint in favor of int whenever one knows for sure 
>> the value
>> wont be negative? That whould be a bit more expressive but on the 
>> other hand
>> sometimes leads to type problems.
>> For example, when having things like this:
>>
>> T min(T)(T a, T b) {
>>   return a < b ? a : b;
>> }
>>
>> Here you whould need to ensure to cast values so they share a common 
>> type.
>>
>> How do you code? Do you use uint whenever it suitable reflects the 
>> data to
>> store (eg a x-y-position on the screen) or only when necessary?
> 
> Current D botches quite a few of the arithmetic conversions. Basically 
> all conversions that may lose value, meaning, or precision should not be 
> allowed implicitly. Walter is willing to fix D in accordance to that 
> rule, which would yield an implicit conversion graph as shown in:
> 
> http://erdani.org/d-implicit-conversions.pdf
> 
> Notice that there is no arrow e.g. between int and uint (loss of 
> meaning), or between int and float (loss of precision). But there is an 
> arrow from int and uint to double, because double is able to represent 
> them faithfully.
> 
> If we are nice, we may convince Walter to implement that soon (maybe in 
> 1.006?) but it must be understood that the tighter rules will prompt 
> changes in existing code.
> 
> To answer your question, with the new rules in hand, using unsigned 
> types will considerably increase your expressiveness and your ability to 
> detect bugs statically. Also, by the new rules ordering comparisons 
> between mixed-sign types will be disallowed.

When this change occurs (since it seems like it will) is there any 
chance that the default opEquals method in Object could have its 
signature changed from:

     int opEquals(Object o);

to:

     bool opEquals(Object o);

Not doing so would disallow the following seemingly legal statement:

     bool c = a == b;

This issue has come up before, and it was shown that the bool rval case 
can be made no less efficient than the int rval case, so the only 
remaining problem is all the code that would break.  However, since a 
lot of code will probably break anyway with the tighter implicit 
conversion rules, perhaps it would be a good time to address this issue 
as well?


Sean