dmd 1.046 and 2.031 releases

[Walter Bright]

Robert Jacques wrote:
> So by the spec   (and please correct me if I'm reading this wrong)
> g = e + f => g = cast(long)(  cast(integer)e + cast(integer)f  );
> where integer is unbounded in bits (and therefore has no overflow)
> therefore
> g = e + f;  => d = cast(long) e + cast(long) f;
> is more in keeping with the spec than
> g = cast(long)(e+f);
> in terms of a practical implementation, since there's less possibility 
> for overflow error.

The spec leaves a lot of room for implementation defined behavior. But 
still, there are common definitions for those implementation defined 
behaviors, and C programs routinely rely on them. Just like the C 
standard supports 32 bit "bytes", but essentially zero C programs will 
port to such a platform without major rewrites.

Silently changing the expected results is a significant problem. The guy 
who does the translation is hardly likely to be the guy who wrote the 
program. When he notices the program failing, I guarantee he'll write it 
off as "D sux". He doesn't have the time to debug what looks like a 
fault in D, and frankly I would agree with him.

I have a lot of experience with people porting C/C++ programs to Digital 
Mars compilers. They run into some implementation-defined issue, or rely 
on some bug in B/M/X compilers, and yet it's always DM's problem, not 
B/M/X or the code. There's no point in fighting that, it's just the way 
it is, and to deal with reality means that DM must follow the same 
implementation-defined behavior and bugs as B/M/X compilers do.

For a C integer expression, D must either refuse to compile it or 
produce the same results.

> (Caveat: most 32-bit compilers probably defaulted integer to int, though 
> 64-bit compilers are probably defaulting integer to long.)

All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers are 
setting int at 32 bits for sensible compatibility reasons.