Don Wrote: > Walter Bright wrote: > > Don wrote: > >> > >> (This means that double y = int_val / 1; is OK, and also: > >> double z = 90/3; would be OK. An alternative rule would be: > >> "If an integer expression involves integer divison, that expression > >> cannot be implicitly cast to a floating-point type"). > > > > This is kinda complicated if one has, say: > > > > double z = x/y + 3; > > Integer expressions remain inexact until there's a cast. > > (It's very simple to implement, you just use the integer range code, > adding an 'inexact' flag. Division sets the flag, casts clear the flag, > everything else just propagates it if a unary operation, or ORs the two > flags if a binary operation).
Assuming it really is this easy, I'd love to see the change. I've run into this bug countless times reviewing code, and it can be a tricky one to find. I tend to be pretty particular about always appending the ".0" for literals involved in floating-point assignments for this reason.
