Warn if type-name in parameter-position

[lukaslueg]

I was surprised that one can confuse himself like in the cooked-up example below: Specifying a concrete type for a parameter on an impl does what one expects. This might lead to the expectation that you can specify a concrete type for a parameter on an fn, which is not the case:

struct Foobar<T>(T);

trait Foo {
    fn bar<H>(&self, b: H) where H: std::fmt::Display ;
}

// `String` is a type...
impl Foo for Foobar<String> {
    // `String` is not a type, it's a type-parameter named `String`.
    // This is almost guaranteed to be wrong!
    fn bar<String>(&self, _b: String) where String: std::fmt::Display {}
}

Here, String does not refer to the type String but is still a generic parameter, now named String instead of H.

If we don't specify the Display-bound, the compiler even helpfully suggests to add the requirement String: Display, which we can do right away. We can use fn bar<u32>(...) and the compiler will warn that u32 should be upper-cased.

Maybe the compiler could warn if a parameter is given the name of a type that is in scope? Something to the tune of

The type-parameter named String in fn bar<String>(...) has the same name as the type std::string::String in the local scope. Be aware that this declares a type-parameter named String. It does not specify a concrete type and might lead to confusion. The original definition is fn bar<H>(...)

[ExpHP]

Note that Clippy implements a builtin_type_shadow lint meant to catch similar mistakes, but it unfortunately does not catch this particular example because String is not a primitive type.

[kpreid]

A lint for when a type parameter name is equal to the name of a type in scope would also catch a mistake I have seen several times (example from today). Minimal example:

struct Foo<T> { x: T }

// error:
impl<String> Foo<String> {}
// should be:
impl Foo<String> {}

That is, they want to write an impl for a concrete type, and they try just putting the concrete type name in place of the type parameter everywhere, instead of changing impl<T> to impl.

(A lot of beginners have gotten to writing generic impls before fully understanding why a generic impl contains <T> twice, or even that one is a declaration and one is a use. Or someone can make this mistake editing “on autopilot” despite understanding.)