On Tue, 07 Jul 2009 11:36:26 -0400, Andrei Alexandrescu
<[email protected]> 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?
