unsigned policy

Andrei Alexandrescu (See Website For Email) SeeWebsiteForEmail at erdani.org
Wed Feb 7 23:24:12 PST 2007


Bradley Smith 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.
>>
>>
>> Andrei
> 
> Does this mean that int would no longer implicitly convert to bool?
> For example, the following would not longer compile.
> 
>   int i = 1;
>   if (i) {}
> 
> This would instead give an error something like "no implicit conversion 
> from int to bool".

if (i) {} does not mean that i is converted to a bool and then tested. 
It's just a shortcut for if (i != 0) {}.


Andrei



More information about the Digitalmars-d mailing list