Why is replace_consts enabled by default?

[gnzlbg]

The replace_consts lint is enabled in clippy-pedantic by default.

The docs hints that using consts is bad because const fn exists.

This does not make any sense to me: why should const fn be preferred over consts? Are associated consts also bad?

[oli-obk]

Are associated consts also bad?

no, but there are none ;)

std::i32::MAX is not i32::MAX, but i32::max_value() is on the type

This does not make any sense to me: why should const fn be preferred over consts?

the const fns for integers are disputed, but the const fns for atomics are the way to go, the old constants were hacks that existed because of the lack of const fn.

see also the discussion on the PR adding this lint #2344

[gnzlbg]

FWIW I got this error on std::usize::MAX.

but the const fns for atomics are the way to go

This makes sense.

[gnzlbg]

Maybe what this lint needs is just better docs? The argument that ::std::usize::MAX needs the whole path, but usize::max_value() does not because it works on the type is a good one actually.

[gnzlbg]

So I think the main arguments are:

• it is more idiomatic to directly associate constants with a type than to put them in a module that only contains the type using associcated consts or const fn
• this allows you to use the constant without the full path, like so usize::max_value().
• now that associated consts are stable there is discussion about moving these constants into these types, and deprecating the module level ones (so using the module level ones should not be encouraged)

@petrochenkov you had strong thoughts about this. How would you document this?

[phansch]

rust-lang/rust#68952 stabilized the assoc_int_consts feature for Rust 1.34. For Clippy this is relevant for at least the replace_consts lint:

As far as I can tell, that lint was meant to suggest to use the associated methods on the integer primitives, instead of the constants that have now been soft-deprecated in rust-lang/rust#68952. Although, the lint doesn't really provide a reason why one is better over the other. (Please correct me if I misunderstood that lint)

The RFC also mentions a deprecation of the associated functions the lint is currently suggesting, so we might want to deprecate replace_consts altogether.

[oli-obk]

We can keep it but suggest moving from module consts to associated constant instead of to associated functions

[tesuji]

This could be closed now with #5380.