Oh Dear

[Walter Bright]

Andrei Alexandrescu wrote:
>> 1. it would cause D code to silently produce different results than 
>> the corresponding C/C++ code. This is extremely important, as I 
>> guarantee that when someone new tries porting existing C code to D, 
>> and it doesn't work, their conclusion will not be "perhaps I should 
>> recode the / expression", it will be "D sux". Note that there is no 
>> way the compiler could issue a warning about this as it cannot 
>> determine a dependency on the rounding method.
> 
> But C gives the implementation leeway to define '/' as they find fit. 
> This is useless because it makes it difficult to write portable code. We 
> must improve on that.

Right, but the de-facto behavior for C compilers is do behave as D 
currently does.

>> 2. it is slower than the current method.
> 
> We want something well-defined. I agree to adopt the semantics of IDIV 
> but we must understand that those might be slower on other machines.

Yes - not only do I think that is ok, but CPUs have been for a long time 
designed to accommodate C, and the de-facto way C does things, including 
the divide. I don't expect this to change, so I don't expect a penalty 
on some future processor because of it.