Bounds on return types in supertraits are not implied

[djkoloski]

This is an issue with the unstable return_type_notation feature.

I'm trying to write some code that provides Send-able versions of traits that may contain async functions:

#![feature(
    async_fn_in_trait,
    return_position_impl_trait_in_trait,
    return_type_notation
)]

use tokio::task::{JoinHandle, spawn};

trait Foo {
    async fn bar(&self) -> i32;
}

trait SendFoo: Foo<bar(): Send> + Send {}

fn foobar(foo: impl SendFoo) -> JoinHandle<i32> {
    spawn(async move {
        let future = foo.bar();
        future.await
    })
}
<code>

Gives the error:

error[E0277]: `impl Future<Output = i32>` cannot be sent between threads safely
  --> src/lib.rs:15:21
   |
15 | fn foobar(foo: impl SendFoo) -> JoinHandle<i32> {
   |                     ^^^^^^^ `impl Future<Output = i32>` cannot be sent between threads safely
   |
   = help: the trait `for<'a> Send` is not implemented for `impl Future<Output = i32>`
note: required by a bound in `SendFoo`
  --> src/lib.rs:13:27
   |
13 | trait SendFoo: Foo<bar(): Send> + Send {}
   |                           ^^^^ required by this bound in `SendFoo`

For more information about this error, try `rustc --explain E0277`.

I expected the SendFoo: Foo<bar(): Send> bound to mean "anything that implements SendFoo also has a bar() which implements Send" (I think this is implied bounds?). Instead, it appears to function like a where clause on a trait (non-implied). It's acting like I wrote:

trait SendFoo: Foo + Send
where
    <Self as Foo>::bar(): Send,
{}

(note that this syntax is not currently accepted by the compiler, but it gets the point across)

Are these bounds supposed to not be implied? As an aside, the error message here tripped me up for a while too.

Meta

rustc --version --verbose:

rustc 1.72.0-nightly (37998ab50 2023-06-11)
binary: rustc
commit-hash: 37998ab508d5d9fa0d465d7b535dc673087dda8f
commit-date: 2023-06-11
host: x86_64-unknown-linux-gnu
release: 1.72.0-nightly
LLVM version: 16.0.5

[compiler-errors]

(afaict) it's not defined anywhere whether these bounds are implied or not. A similar issue happens with associated_type_bounds, which I've been meaning to file a bug for and T-lang nominate. Let me do that now, since afiact this issue and that one (which is less tied up in still-experimental syntax) are the same.