Trait-objects need associated-types of subtraits to be specified even when that's already done by the boxed trait

[qrlpx]

If someone has a shorter/more conclusive title in mind, shoot.

code

trait Foo {
    type Bar;
}

trait FooBar: Foo<Bar = String> {}

struct Arb {
    foobar: Box<FooBar>,
}

Playpen: http://is.gd/6QKndB

output

test.rs:8:17: 8:23 error: the value of the associated type `Bar` (from the trait `Foo`) must be specified [E0191]
test.rs:8     foobar: Box<FooBar>,
                          ^~~~~~
test.rs:8:17: 8:23 help: run `rustc --explain E0191` to see a detailed explanation
error: aborting due to previous error

rustc version

rustc 1.5.0-nightly (0be1bcd06 2015-10-24)

[arielb1]

I would like to claim that this is a part of "non-supertrait predicates are not elaborated", but this quite ugly.

However, with the current acyclicity requirements, this would break stuff like

trait Foo : Iterator where Self::Item: Copy {}

Maybe just give them the ProjectionPredicate treatment?

[gwillen]

I just hit this issue and discovered this bug by searching. I don't understand most of the words in the comment explaining why this behavior is this way. :-) But it's definitely a weird UX issue, in that it's not at all obvious to a user why it would do this.

[Wyverald]

This also makes it hard to parameterize associated types.

trait Foo { type Bar; }
trait Foobar<T> : Foo<Bar=T> {}
struct Quux<'a> {
    foobar: &'a Foobar<String>,
}

That doesn't compile. I'll need to write foobar: &'a Foobar<String, Bar=String> instead.

[durka]

In combination with Fn traits, this seems like a hole in stability! Check out this code:

trait FnAlias: Fn() {}

fn main() {
    let _: FnAlias;            // error
    let _: FnAlias<Output=()>; // no error, but I shouldn't be able to do this!
}

Normally I can't write an Fn trait while specifying the return type as an associated type, at least without #![feature(unboxed_closures)]. But here I have to.

[peterhj]

Appears to be the same as #23856 and possibly #24010?

[bstrie]

Tagging with A-stability based on durka's comment.

[nikomatsakis]

So while it's true that this bug allows you to name the Output parameter, in a sense, of the Fn traits, which we are normally not permitting, I don't think there is any plan to change the Fn traits in a way that would make this a problem. Still, an interesting thing.

[nikomatsakis]

In particular, we are more concerned about the input argument types, which may want to become variadic or otherwise change.

[nikomatsakis]

triage: P-medium

[nikomatsakis]

Closing as dup of #24010