`impl Trait` Associated Types Do Not Leak Auto Traits

[cramertj]

While auto trait impls of impl Trait types leak, the auto trait impls of their associated types do not:

#![feature(conservative_impl_trait)]

trait Foo {
    type Bar;
}

fn require_bar_send<F>(_: F) where F: Foo, F::Bar: Send {}

fn foo() -> impl Foo {
    struct Fooey;
    impl Foo for Fooey {
        type Bar = ();
    }
    Fooey
}

fn main() {
    require_bar_send(foo()); // ERROR
}

This can be fixed by writing impl Foo<Bar=impl Send>, but this can get annoying quickly: async traits, whose methods each return a separate associated type implementing Future, need to have a Bar=impl Send for each method:

trait Foo {
    type FooFut: Future<...>;
    fn foo(&self) -> Self::FooFut;

    type BarFut: Future<...>;
    fn bar(&self) -> Self::BarFut;

    type BazFut: Future<...>;
    fn baz(&self) -> Self::BazFut;
}

fn foo() -> impl Foo<FooFut=impl Send, BarFut=impl Send, BazFut=impl Send> { ... }

This isn't a bug, but I'm interested in seeing if there're ways we can improve here-- should associated type auto traits leak? I can see that becoming a huge problem since you'd then want the associated types of associated types auto traits to leak, etc, but there's not an obvious solution to me. I really just want an "everything you care about here is thread-safe" button, but I don't know how to supply that easily.

[cramertj]

Probably the right solution for my particular case is first-class async fn in traits, where the future returned from async fn foo(&self) is guaranteed to be Send so long as Self: Send. cc @withoutboats

[Centril]

Assuming the following is legal:

trait SendFoo = Foo<FooFut = impl Send, BarFut = impl Send, BazFut = impl Send>;

fn foo() -> impl SendFoo { ... }

it does seem like an ergonomic effect to do write things.

If we gain ConstraintKinds or "trait-parametric polymorphism", then you could also write:

trait ExtraFoo<trait X> = Foo<FooFut = impl X, BarFut = impl X, BazFut = impl X>;

fn foo() -> impl ExtraFoo<Send> { ... }

which is general and polymorphic over any extra trait you like.

Instead of leaking auto traits in assoc types, I'd like to go the other direction and not leak auto traits anywhere.

[Nemo157]

I'm running into this a lot now while trying to use async "handlers" that return associated future types, and being generic over some other type, while hiding details behind impl Trait. Here's a playground with a full example of the kind of code I'm trying to write. It's not possible to just start adding + Send + Sync bounds to the returned types since they're only Send + Sync when the provided generic is also Send + Sync, so this needs either leakage, or some way to specify conditional bounds in impl Trait.