Adding lint to detect lossy whole number floating-point literals

[krishna-veerareddy]

Would adding a lint to detect whole number floating-point literals that are lossy when represented as floats be something useful. Here are a few examples:

// f32 example
let _: f32 = 16_777_219.0; // represented as 16_777_220.0
let _: f32 = -16_777_219.0; // represented as -16_777_220.0

// f64 example
let _: f64 = 9_007_199_254_740_993.0; // represented as 9_007_199_254_740_992.0
let _: f64 = -9_007_199_254_740_993.0; // represented as -9_007_199_254_740_992.0

For f32 maybe we could suggest upcasting to an f64. Not sure what we could suggest for f64 but we could at the least warn that the literal would be lossy. Would love to know your thoughts and if it is worth adding this to clippy then I can start working on it but if not feel free to close it.

[flip1995]

I think if someone types out a float literal that are so long, that it cannot be represented in a float number, probably he/she wanted the exact number. So I think we can make this even a correctness lint.

[krishna-veerareddy]

@clarfon Hey any thoughts on this?

[clarfonthey]

I agree-- don't we already technically have a lint for this? Maybe we'd make a warn-by-default lint for this?

[flip1995]

We have 3 lints addressing similar issues:

• approx_constant floats representing PI, E, ... (deny)
• cast_precision_loss general case of int -> float, but doesn't check if the int really loses precision during the cast. (allow)
• excessive_precision decimal part of the float cannot be represented (warn)

[krishna-veerareddy]

Of the three similar issues excessive_precision sounds close enough to what we are trying to achieve so maybe we could extend it to account for whole number floats that are lossy. It is warn by default but its in the style category so maybe that is going to be an issue. Thoughts?

[flip1995]

I think we can uplift excessive_precision to correctness, because the behavior of the code is different to the behavior the author intended. Or we just keep it in style, but I don't think style is a fitting group for this lint.

[krishna-veerareddy]

Yeah style doesn't seem like the right category for this so I uplifted it to the correctness category.