为什么在 rust 中关联泛型类型的名称冲突是合法的？

Question

I find that I convert trait generics:

trait Foo<TItem> {
    fn clone(&self, item: TItem) -> TItem { 
        item.clone() // <-- ah, it needs + Clone
    }
}

...into associated types:

trait Foo {
    type TItem : Clone;
    fn clone(&self, item: Self::TItem) -> Self::TItem {
        item.clone()
    }
}

Reasonably often. However, today I made a typo when doing this, and as a result I got:

trait Foo<TItem> {
    type TItem : Clone;
    fn clone(&self, item: TItem) -> TItem {
        item.clone()
    }
}

Which results in an error:

1 | trait Foo<TItem> {
  |           ----- method `clone` not found for this type parameter
...
item.clone()
     ^^^^^ method not found in `TItem`

In this case, the error is obvious, but in some cases, the error reporter cannot resolve the related generic, resulting in more obscure errors such as this real-world example:

error[E0599]: the method `clone` exists for struct `Vec<TItem>`, but its trait bounds were not satisfied
191 |         let b = matched.1.clone();
    |                           ^^^^^ method cannot be called on `Vec<TItem>` due to unsatisfied trait bounds
    |

So, long story short, yes, I know that TItem and Self::TItem are distinct types and can be referenced separately, however, what I don't understand is why this possible.

Wouldn't it make sense for Self::X and X to share a common namespace and result in previous definition of the type 'TItem' here ?

Have I over looked something? Is there any use-case for Self::Foo and Foo to both exist on a trait? ...or is this just a legacy thing, that exists for compatibility reasons?

To try to make this a more specific and concrete question, the original RFC says:

struct Foo { ... }

trait Bar<Input> {
    type Foo; // this is allowed
    fn into_foo(self) -> Foo; // this refers to the trait's Foo

    type Input; // this is NOT allowed <------------
}

However, this is legal now, as you can see from this play link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=92f9b44c30d44192a77cac8ffee5d142

What changed?

I'll accept any answer that can point me to an RFC / discussion that indicates why the accepted RFC is no longer correct.

Answer 1

Wouldn't it make sense for Self::X and X to share a common namespace and result in previous definition of the type TItem here?

Yes, it would make sense on first glance, and that was originally the plan. You can find proof of that from the RFC itself which has this example code:

trait Graph {
    type N;
    type E;
    fn has_edge(&self, &N, &N) -> bool;
}

Note how Self::N is not used.

You can also find proof of that in comments from Rust core team members such as Niko who made comments like this :

Instead one ought to write T , Self::T or (maximally explicit) <Self as Foo>::T .

Note how T is talked about as equivalent to Self::T .

What changed?

After the RFC was accepted, it was decided to NOT allow plain T to refer to associated types, because it would lead to a lot of tricky ambiguity problems that would have to be solved. You can find the full discussion here , where you find this at the end (also by Niko):

For the record I feel...fairly uncomfortable with a scoping rule that puts assoc type resolution as a fallback [to regular generic type parameters].

In other words: "if we allow this, we need to solve several tricky follow-up problems". And then follows the decision to require Self::

We decided at the weekly meeting today that we would stick with requiring Self:: rather than implementing this shorthand.

Summary

The implementation of associated types was never "complete". Instead, it has been done in smaller incremental steps. See for example this comment from one of the implementors of associated types:

This patch is already huge so I'd like to implement that in a followup.

Because of the incremental nature of implementing support for associated types, and because of the decision to deviate from the original RFC, it is currently possible to have both a generic type parameter named T and an associated type named T .

Answer 2

The names don't conflict. Your second code snippet doesn't compile, which illustrates that:

error[E0412]: cannot find type `TItem` in this scope
 --> src/lib.rs:3:27
  |
3 |     fn clone(&self, item: TItem) -> TItem {
  |                           ^^^^^ help: you might have meant to use the associated type: `Self::TItem`

The associated type is Self::TItem and the generic type is TItem . They cannot be used interchangeably, and one cannot mean the other. There is therefore no reason to disallow them to have the same name.