Lint requiring underscores for numeric literal suffixes (2021 breaking change suggestion)

Based on comments from On the futility of error checking (anecdotal):

Could we deprecate the use of numeric literal suffixes without _ separating them from the value? I.e., these would no longer be allowed:

5i32
2.3e10f64

Instead, the permitted way to write them would be:

5_i32
2.3e10_f64

Additionally, to catch the specific bug that inspired that thread, could we consider requiring a type suffix when using the exponent (e or E) literal notation? I.e., this would no longer be permitted:

2.3e10

Instead, it would need to be one of:

2.3e10_f32
2.3e10_f64
2 Likes

I think the path for that would be a default-allow lint, and add it to rust-2021-idioms. This is mostly a style issue though, so I don't think it's necessary to go for a breaking change.

To me this feels like a stylistic choice, so I'd don't think I'd ever be in favour of making it a hard error.

Of course, I always use underscored suffixes myself so I'd be fine with making a warn-by-default lint about it, though I'm not sure whether that would be better in clippy or rustc.

(Really I wish we could just have 1.0: f32 instead of the suffixes, but that doesn't seem like it's happening any time soon.)

1 Like

Ah, clippy does have it:
https://rust-lang.github.io/rust-clippy/master/#unseparated_literal_suffix

BTW, 1_e32 and 1_f32 are both legal...

2 Likes

Right; hence the second part of the suggestion, which would require 1_e32 to be either 1e32_f32 or 1_e32_f32. (Or a different size.)