More DRY code for const definitions that contain an as cast

[leonardo-m]

What it does

It suggests to replace a coding pattern that isn't DRY enough when there's a cast in a const definition. This is a spinoff of issue #15163 .

Advantage

Less types to read, less code to change if needed, code more DRY.

Drawbacks

I can't think of any drawback. But perhaps there are some.

Example

In the wild (Linux) I've seen Rust code like this:

const BMCR_SPEED100: u16 = uapi::BMCR_SPEED100 as u16;

This is similar but simplified code:

#![warn(clippy::all)]
#![warn(clippy::nursery)]
#![warn(clippy::pedantic)]
fn main() {
    const M: usize = 100;
    const N: u16 = M as u16;
}

I think a new Clippy lint could suggest instead:

const N: u16 = M as _;

[briansmith]

const N: u16 = M as _;

I don't think we should ever recommend as _. We have as_udnerscore to recommend against that pattern.

What we need to recommend is a const fn that clearly indicates truncation from a larger type to the smaller type. But we have no such function in libcore/libstd we can recommend. It is common for people to define a const fn u16_from_u32(a: u32) -> u16 { a as u16 } or similar and then use that. But, Clippy can't know about such functions. So I think the code as given is as good as it can be, as far as Clippy is concerned.

[leonardo-m]

I've taken a look at that lint:
https://rust-lang.github.io/rust-clippy/stable/index.html#/as_underscore

I fires in situations like:

fn foo(n: usize) {}
let n: u16 = 256;
foo(n as _);

I agree that in such situations using _ isn't a good idea, because if you change the argument type n, the code still compiles, but it could now silently truncate (if n becomes an u8). The link I'm proposing works in a different situation, when you are defining a const, and you already stated the type on the right:

const N: u16 = M as _;

There's no ambiguity here, and if you cast to a narrower type you could see it. Also DRY code has some advantages, you don't need to change the code in two points if you need to change the type of the constant. So the lint I'm suggesting add a nuance to the idea that using "as _" is often a bad idea :-)

If you still wish to close down this issue then it's OK, this isn't an important lint.