unsigned policy

[Andrei Alexandrescu (See Website For Email)]

Sean Kelly wrote:
> 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?

It's up to Walter. Also I haven't heard word about dropping the implicit 
bool-to-int conversion.

What I think is reasonable:

int x;
if (x) {} // should work: compare x against zero
bool y;
if (y) {} // should work :o)
y = x;    // should not work, use y = (x != 0);
x = y;    // should not work, use x = cast(bool)y or x = y ? 1 : 0

The last rule seems overkill, but really it's rare that you want to 
convert a bool to an integer, and when you do, many people actually do 
use the ?: notation to clarify their intent.


Andrei