dmd 1.046 and 2.031 releases

[Andrei Alexandrescu]

Robert Jacques wrote:
> On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at 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