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.
