Tracking Issue for return type notation

[compiler-errors]

This is a tracking issue for the feature return type notation specified in rust-lang/rfcs#3654.
The feature gate for the issue is #![feature(return_type_notation)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the feature
  • Support RTN in associated type bounds (Initial support for return type notation (RTN) #109010)
  • Support RTN with (un-)qualified path syntax (e.g. where T::method(): Send) Implement Return Type Notation (RTN)'s path form in where clauses #129629
• Author RFC: RFC: Return Type Notation rfcs#3654
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved questions

• Does stabilizing T::foo(..) notation as a standalone type create a confusing inconsistency with -> () shorthand?

Experimental results

Part of the goal of the experimental process is to identify benefits but also concerns that need to be addressed in the RFC.

• Alternative: typeof syntax.
• Concerns raised by lcnr

Implementation history

• Initial support for return type notation (RTN) #109010

[VictorBulba]

hey

Is there a way to use this the following way?

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

use std::future::Future;

trait Inner: Send + Sync {
    async fn do_async(&self);
}

trait Outer {
    type In: Inner<do_async(): Send>;
} 

fn foo<T>(inner: T::In) -> impl Future + Send
where
    T: Outer,
{
    async move {
        inner.do_async().await;
    }
}

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d69310a05735ec25356754d4b8bdd708

[programmerjake]

somewhat related: we may want to change async functions to return impl IntoFuture instead of impl Future so we can eventually replace Pin with !Move as outlined here -- having Send bounds everywhere on the direct return type which would be impl IntoFuture with that change but not the Future type makes that edition change much more difficult, so imo we should consider alternatives, one of which is somehow making Trait::my_async_fn(..): Send also imply the Future is Send either by adding that bound as a desugaring or requiring the new Pin-less IntoFuture to have Self: Send imply Self::IntoFuture: Send

[slanterns]

The parentheses clearly indicates it's the eval result (output, return type) of the function, not the function itself.