Andrei Alexandrescu wrote:
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
You could add modular arithmetic types. They are frequently
useful...though I admit that of the common 2^n basis bytes are the most
useful, I've often needed base three or other. (Probably not worth the
effort, but modular arithmetic on 2^n for n from 1 to, say 64 would be
reasonably easy.
