What it does

ptr_cast_constness warns about as casts, suggesting cast_const() in e.g.

let p = core::ptr::null_mut();
let p: *const i32 = p as _;

However, if one relies on coercion, it does not warn:

let p = core::ptr::null_mut();
let p: *const i32 = p;

This is fine for ptr_cast_constness -- after all, the documentation mentions it checks for as.

Does it make sense to have a lint that suggests cast_const() in the second example too?

Personally, I don't know if avoiding the coercion is a good idea to begin with, but given the existence of cast_const() and the following sentence in its docs, I decided to open this:

may have documentation value if used instead of implicit coercion.

The lint would need to be opt-in.

Advantage

Like the cast_const() docs mention, it "may have documentation value if used instead of implicit coercion".

It could be useful for projects that wish to be written in a more explicit (and symmetric) style around raw pointers.

Drawbacks

Ergonomics can be worse in some cases, e.g. see the type annotation needed in the example below.

Example

let p = core::ptr::null_mut();
let p: *const i32 = p;

Could be written as:

let p: *mut i32 = core::ptr::null_mut();
let p: *const i32 = p.cast_const();

Note that : *mut i32 was added in the first line as well.