lint idea: useless_default_generic_parameters

[y86-dev]

What it does

Given a type with a generic argument that has a default:

type Result<T = ()> = core::result::Result<T, MyError>;

Usage of this type when specifying the default should not use generics:

fn foo() -> Result<()> { Ok(()) }
//                ^^^^ unnecessary generic, `()` already is the default
//                hint: use `Result` instead.

Advantage

• Removes duplication of the default value
• Reduces visual clutter
• Reminds people that the type has a default value

Drawbacks

• when a library adds a default value, one gets this warning when updating
• macros might trigger this involuntarily

Example

type Result<T = ()> = core::result::Result<T, MyError>;

fn foo() -> Result<()> {
    Ok(())
}

Could be written as:

type Result<T = ()> = core::result::Result<T, MyError>;

fn foo() -> Result {
    Ok(())
}

[dakr]

+1, I think that's a good idea.

[y86-dev]

I'm not 100% satisfied with the name of the lint "unnecessary_generic", but I also couldn't come up with something better.

[ojeda]

+1, we had this as Rust-for-Linux/linux#1128 as a kernel-specific checkpath.pl "lint", but if Clippy can do this, that would way better: it would cover more projects and more generic types.

[samueltardieu]

It has to work with allow/deny sentences, such as in "allow useless default parameters", so useless_default_parameters or something like that might be an option.

[y86-dev]

+1, we had this as Rust-for-Linux/linux#1128 as a kernel-specific checkpath.pl "lint", but if Clippy can do this, that would way better: it would cover more projects and more generic types.

Ah I see, I didn't check, since I think putting this in clippy is the right way, there is nothing kernel-specific or obscure about this lint :)

[y86-dev]

It has to work with allow/deny sentences, such as in "allow useless default parameters", so useless_default_parameters or something like that might be an option.

that sounds much better :)

[ojeda]

Ah I see, I didn't check, since I think putting this in clippy is the right way, there is nothing kernel-specific or obscure about this lint :)

Yeah, definitely.

(To clarify, they are not exclusive, i.e. ideally it would be faster to add a checkpatch.pl, which applies to all Rust versions and may help justify a Clippy lint, but sadly I don't think there is much bandwidth on the checkpatch.pl side).

[Jarcho]

explicit_default_arguments might be better. The implementation has to avoid linting anywhere type inference happens so check_ty can't be used.