unsigned policy

[Derek Parnell]

On Wed, 07 Feb 2007 22:46:02 -0800, 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".

I hope it would cause this error. Unless the compiler treats this a
shorthand for if (i != 0) {}

> If this were the case, wouldn't it make the expression (a < b < c) 
> illegal, as is being discussed in another thread. Since "a < b" would 
> result in a bool, but bool < int is not a legal comparison.

Not so I think, because the bool would be converted to an int then the
comparison would take place.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
8/02/2007 5:52:03 PM