A division problem

[Don]

On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
> This kind of code sometimes is wrong, because you forget to 
> cast x to double before the division and you lose precision 
> (but here the compiler knows that the result of the division 
> will go inside a double):
>
>
> void main() {
>     int x = 15;
>     double y = x / 10;
> }
>
> The cause is that unfortunately in D the integer division uses 
> the same operator as the FP division. In Python there is the / 
> and // operators. In OcaML there are the / and /., in Delphi 
> there are the / and div operators, in Ada the two operands need 
> to be of the same type.
>
> Seasoned C/C++/D programmers watch for the types every time 
> they perform a division, to avoid that trap. But less 
> experienced programmers introduce bugs with divisions. Can D 
> help the programmer reduce the frequency of similar bugs? And 
> do we want to?
>
> Bye,
> bearophile

It is indeed a common floating-point bug.

I came up with a solution for this a couple of years ago, never 
got around to doing a pull request, but it's on the newsgroup 
somewhere. It's a little extension to the range propagation 
implementation. You add a boolean flag to the range, which 
indicates 'a fractional part has been discarded'. This flag gets 
set whenever you perform an integer division (or integer 
exponentiation with a negative power), and is cleared whenever 
there is a cast or a bitwise operation.

Then, disallow implicit casting from integer to floating point 
whenever the fractional bit is set. Catches all these kinds of 
bugs, doesn't require any changes to the language.