Suggestions for more generic code

Suggestions for more generic code

This was originally posted in rust internals.

What does this lint do?
It would identify if a function can potentially be made generic, and it would suggest how to do it. It would be helpful to have a tool perform this sort of check, so we can occasionally spot this faster.

Categories (optional)

• Kind: pedantic

What is the advantage of the recommended code over the original code
It would be generic.

Drawbacks

Function and variable names that imply any given type may not play well with the suggestion.

Some code can be made generic in different ways, or to different degrees. The example below could use two generics and and the associated type Add::Output.

Also, some code may be generalizable but the generic form may be too verbose or complicated to be helpful. In that case suggestions could be filtered by length. I also fear that almost all functions in a crate may be linted, as traits are used so often instead of ordinary methods. It is quite probable that not all linted functions should be made generic, as they will hardly be used with more than one type.

@kornelski also mentioned that generics have a compilation cost, specially with library code.

Example

fn print(x: &str) {
   println!("{}", x);
}

fn add(x: i32, y: i32) -> i32 {
   x + y
}

Could be written as:

warning: potential use of generic code.
   --> src/main.rs:3:0
    |
3   |         fn print(x: &str) {
    |             ^ help: try changing `&str` to `&impl Display`
    |
    = note: `#[warn(generalizable_code)]` is on 
warning: potential use of generic code.
   --> src/main.rs:3:0
    |
7   |         fn add(x: &str) {
    |             ^ help: try changing `add<T: std::ops::Add>(x: T, y: T) -> T`
    |
    = note: `#[warn(generalizable_code)]` is on 

warning: 1 warning emitted

Start with the linked Rust Internals discussion and the example functions in this issue. Determine the scope and feasibility of a lint that identifies opportunities for generic code while accounting for ambiguity, verbosity, naming, and compilation cost. Done would require an agreed design and an implemented, tested lint.