dmd 1.046 and 2.031 releases

[Robert Jacques]

On Tue, 07 Jul 2009 11:36:26 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:
> Robert Jacques wrote:
>>  Andrei, I have a short vector template (think vec!(byte,3), etc) where  
>> I've had to wrap the majority lines of code in cast(T)( ... ), because  
>> I support bytes and shorts. I find that both a kludge and a pain.
>
> Well suggestions for improving things are welcome. But I don't think it  
> will fly to make int+int yield a long.

Suggestion 1:
Loft the right hand of the expression (when lofting is valid) to the size  
of the left hand. i.e.

byte a,b,c;
c = a + b;  => c = a + b;

short d;
d = a + b;  => d = cast(short) a + cast(short) b;

int e, f;
e = a + b;  => e = cast(short) a + cast(short) b;
e = a + b + d; => e = cast(int)(cast(short) a + cast(short) b) + cast(int)  
d; Or e = cast(int) a + (cast(int) b + cast(int)d);

long g;
g = e + f;  => d = cast(long) e + cast(long) f;

When choosing operator overloads or auto, prefer the ideal lofted  
interpretation (as per the new rules, but without the exception for  
int/long), over truncated variants. i.e.
auto h = a + b; => short h = cast(short) a + cast(short) b;

This would also properly handled some of the corner/inconsistent cases  
with the current rules:
ubyte  i;
ushort j;
j = -i;    => j = -cast(short)i; (This currently evaluates to j =  
cast(short)(-i);

And
a += a;
is equivalent to
a = a + a;
and is logically consistent with
byte[] k,l,m;
m[] = k[] + l[];

Essentially, instead of trying to prevent overflows, except for those from  
int and long, this scheme attempts to minimize the risk of overflows,  
including those from int (and long, once cent exists. Maybe  
long+long=>bigInt?)


Suggestion 2:
Enable the full rules as part of SafeD and allow non-promotion in un-safe  
D. Note this could be synergistically combined with Suggestion 1.




>>>> BTW: this means byte and short are not closed under arithmetic  
>>>> operations, which drastically limit their usefulness.
>>>
>>> I think they shouldn't be closed because they overflow for relatively  
>>> small values.
>>  Andrei, consider anyone who want to do image manipulation (or computer  
>> vision, video, etc). Since images are one of the few areas that use  
>> bytes extensively, and have to map back into themselves, they are  
>> basically sorry out of luck.
>
> I understand, but also keep in mind that making small integers closed is  
> the less safe option. So we'd be hurting everyone for the sake of the  
> image manipulation folks.
>
> Andrei

Well, how often does everyone else use bytes?