This seems like what could be a common cause of bugs

[Don]

Andrej Mitrovic wrote:
> This is just an observation, not a question or anything.
> 
> void main()
> {
>     enum width = 100;
>     double step = 1 / width;
> 
>     writeln(step);  // 0
> }
> 
> I've just had this bug in my code. I forgot to make either width or 1
> a floating-point type. IOW, I didn't do this:
> 
> void main()
> {
>     enum width = 100.0;
>     double step = 1 / width;   // or .1
> 
>     writeln(step);  // now 0.01
> }
> 
> This seems like a very easy mistake to make. But I know the compiler
> is probably powerless to do anything about it. It has an expression
> resulting in an int at the RHS, and it can easily cast this to a
> double since there's no obvious loss of precision when casting
> int->double.
> 
> Where's those lint tools for D.. :/

It is indeed a common bug. I made a proposal for fixing it, which was 
accepted, but I still haven't got around to making the patch. It's a 
simple addition to range propagation: integer operations need to record 
if there is a potentially non-zero fractional part in the result.
Non-zero fractional parts are created by /, %, and ^^.
Certain operations (bitwise operations, casts) force the fractional part 
to zero, enabling it to be convertable to float.