Robert Jacques wrote:
On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote:
Robert Jacques wrote:
That's really cool. But I don't think that's actually happening (Or are these the bugs you're talking about?):
     byte x,y;
    short z;
z = x+y; // Error: cannot implicitly convert expression (cast(int)x + cast(int)y) of type int to short
     // Repeat for ubyte, bool, char, wchar and *, -, /

http://d.puremagic.com/issues/show_bug.cgi?id=3147 You may want to add to it.

Added. In summary, + * - / % >> >>> don't work for types 8-bits and under. << is inconsistent (x<<1 errors, but x<<y compiles). All the op assigns (+= *= -= /= %= >>= <<= >>>=) and pre/post increments (++ --) compile which is maddeningly inconsistent, particularly when the spec defines ++x as sugar for x = x + 1, which doesn't compile.

And by that logic shouldn't the following happen?
     int x,y;
    int z;
z = x+y; // Error: cannot implicitly convert expression (cast(long)x + cast(long)y) of type long to int

No. Int remains "special", i.e. arithmetic operations on it don't automatically grow to become long.

i.e. why the massive inconsistency between byte/short and int/long? (This is particularly a pain for generic i.e. templated code)

I don't find it a pain. It's a practical decision.

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.

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

Reply via email to