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

On Wed, 14 Feb 2007 12:24:59 -0800, Andrei Alexandrescu (See Website For
Email) wrote:


> x = y;    // should not work, use x = cast(bool)y or x = y ? 1 : 0

Did you mean ...

  int x;
  bool y;
  x = y;    // should not work, use x = cast(int)y or x = y ? 1 : 0

I'm in full agreement with your bool/int rules, BTW.
-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Derek Parnell wrote:
> On Wed, 14 Feb 2007 12:24:59 -0800, Andrei Alexandrescu (See Website For
> Email) wrote:
> 
> 
>> x = y;    // should not work, use x = cast(bool)y or x = y ? 1 : 0
> 
> Did you mean ... 
> 
>   int x;
>   bool y;
>   x = y;    // should not work, use x = cast(int)y or x = y ? 1 : 0
> 
> I'm in full agreement with your bool/int rules, BTW.

Yah, that's correct, thanks for the fix. Let's hear what Walter has to say :o). In fact, I suggest that we all think of some compelling cases one way or another. We all know of the mess created by implicit bool->int in C++, so let's look for some "positive" example. On both sides.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Derek Parnell wrote:
>> On Wed, 14 Feb 2007 12:24:59 -0800, Andrei Alexandrescu (See Website For
>> Email) wrote:
>>
>>
>>> x = y;    // should not work, use x = cast(bool)y or x = y ? 1 : 0
>>
>> Did you mean ...
>>   int x;
>>   bool y;
>>   x = y;    // should not work, use x = cast(int)y or x = y ? 1 : 0
>>
>> I'm in full agreement with your bool/int rules, BTW.
> 
> Yah, that's correct, thanks for the fix. Let's hear what Walter has to say :o). In fact, I suggest that we all think of some compelling cases one way or another. We all know of the mess created by implicit bool->int in C++, so let's look for some "positive" example. On both sides.

The only one I can think of is using bool as a primitive constrained type.  For example, BitArray can be initialized using an array of bools as:

    BitArray b;
    b.init( [1,0,1,0] );

With the conversion rules in place, this would have to be rewritten as:

    BitArray b;
    b.init( [true,false,true,false] );

Not too pretty :-)  But bool is a logical type so it's really being misused here anyway.  What we really want is:

    alias ${0,1} bit;
    class BitArray { void init( bit[] buf ) {} }

Or something like that.  I've personally never had much of a need to convert bool->int and vice-versa.  In the few instances where this has been necessary, it's easy enough to use:

    int  i;
    bool b;
    b = i != 0;
    i = b ? 1 : 0;


Sean

"Walter Bright" <newshound@digitalmars.com> wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Bill Baxter wrote:
>>> I notice the graph doesn't include complex types.
>>> Is there any reason why float shouldn't be automatically converted to
>>> cfloat?
>>
>> Sharp eyes :o). I was simply too lazy to include complex types. Probably real-to-complex conversion should be allowed implicitly, too, as long as the basic principle of preserving value is respected.
>
> Implicit conversions from floats to complex types was disallowed because it caused overloading problems with math functions.
>
> Separate functions for float and complex functions are desirable.

True, but there has been a proposal for this, which would make it work correctly, and allow for the implicit conversions when needed. :)

I refer you to http://www.digitalmars.com/d/archives/digitalmars/D/36360.html, from last spring.