dmd 1.046 and 2.031 releases

[Charles Hixson]

Andrei Alexandrescu wrote:
> 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
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.