Error extending Fn trait then using it as a trait object: the value of the associated type `Output must be specified

[carllerche]

trait Foo: Fn(i32) + Send { }
impl<T:?Sized + Fn(i32) + Send> Foo for T { }

fn wants_foo(t: Box<Foo>) {
}

fn main() {
  let f = Box::new(|x| println!("{}", x));
  wants_foo(f);
}

Output:

<anon>:9:13: 9:14 error: the value of the associated type `Output` (from the trait `core::ops::FnOnce`) must be specified [E0191]
<anon>:9   wants_foo(f);
                     ^

cc @nikomatsakis

[nikomatsakis]

The problem is that the associated type is defined in a supertrait, and we don't consider that case when we check that the object type is well-formed.

[Diggsey]

It can be quite painful to work around this problem, as it's the only way to create aliases for traits.

When you have bounds such as the following scattered all over the code: Fn(&(Any + Send), &'static str, u32) + 'static, it's much nicer to be able to give it a short name.

[jonhoo]

@Diggsey: what workaround would you propose? I've been hitting my head against this wall for a while now, and am getting nowhere..

[Diggsey]

@jonhoo I don't know about your particular use-case, but for me I was using this to create a short alias for a trait - the workaround was just to use the long name everywhere, ie. Fn(&(Any + Send), &'static str, u32) + 'static

[jonhoo]

My use-case is exactly the same. I was hoping I might be able to use a macro that expanded to the type, but that doesn't seem to work either. I suppose I'll just have to use the full signature for now..

[Kimundi]

@nikomatsakis Why is that case not considered?

[nikomatsakis]

@Kimundi it's a bug, really.

[Kimundi]

Ah, okay it sounded like that was intentional :)

[DGolubets]

Is it going to be fixed in any upcoming version?

[nikomatsakis]

Note that @durka points out in #29328 this does technically allow one to violate some stability restrictions, but probably not in a way that matters:

trait FnAlias: Fn() {}

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

[jimmycuadra]

This bug is very annoying. I have the same use case as @Diggsey and @jonhoo: creating an alias of a trait with cumbersome bounds that I don't want to have to repeat everywhere.

In case it's not obvious from the title, this doesn't have to do with the Fn trait specifically. It's just about supertrait associated types being ignored when using the subtrait. Here's a simpler illustration:

trait A {
    type Assoc;
    // Pretend there are several more associated types here to make uses of `Box<A>` inconvenient.
}

trait B: A<Assoc=()> {}

fn takes_b(b: Box<B>) {}

which results in:

error[E0191]: the value of the associated type `Assoc` (from the trait `A`) must be specified
 --> src/lib.rs:8:19
  |
8 | fn takes_b(b: Box<B>) {}
  |                   ^ missing associated type `Assoc` value

The compiler should be able to infer that type Assoc = () here.