Permit unqualified references to associated types of the trait within the trait definition

[emberian]

#![feature(associated_types)]
pub trait Transfer {
    type Result;
    fn transfer(&mut self) -> Result;
}

fn main(){}

Gives the error:

foo.rs:4:31: 4:37 error: wrong number of type arguments: expected 2, found 0
foo.rs:4     fn transfer(&mut self) -> Result;
                                       ^~~~~~

According to the RFC the Result ought to refer to the associated type.

[emberian]

Also:

#![feature(associated_types)]
pub trait Transfer<S> {
    type R;
    fn transfer(&mut self) -> R;
}

fn main(){}

foo.rs:4:31: 4:32 error: use of undeclared type name `R`
foo.rs:4     fn transfer(&mut self) -> R;
                                       ^
error: aborting due to previous error

[nikomatsakis]

Updated title for precision.

[Gankra]

This makes refactoring code to use associated types a lot more painful, and adds another straw to the camel's back of associated types being less ergonomic than Foo<A, B, C, D> soup.

[aturon]

There's been some debate on whether this feature should go forward. The main objection, I believe, is that the RFC brings into scope all items of the trait itself, but not any super traits. This is partly due to hygiene concerns, and partly due to the fact that the notion of a "super trait" is somewhat blurred with generalized where clauses. It may be problematic to have to sometimes write Self::T and other times T.

Personally, I think the ergonomic and readability benefits are worth it even if in edge cases the Self:: is required. I would also like to be more certain that there are hygiene problems before we close the door to bringing in super trait items.

[aturon]

Nominating for beta milestone: we need to at least make a decision on this topic before then.

This makes refactoring code to use associated types a lot more painful, and adds another straw to the camel's back of associated types being less ergonomic than Foo<A, B, C, D> soup.

Was that supposed to be one of the goals of moving to associated types? I have no idea but would have expected it was more about expressivity (with some cost in terms of ergonomics). In any case, I'm sort of on the fence about this one. I think I find having the Self::X makes it easier to read and understand the code at a glance, particularly when there are a lot of other parameters in the mix.

[Gankra]

@darinmorrison it would be nice if the common case for generics didn't become harder, regardless of explicit goals. Especially with new Orphan/Impl checks forcing associated types.

[aturon]

Whatever decision we make here should apply to impls as well.