impl trait in traits brainstorming doc

Context

In the short term, I expect to stabilize named impl Trait, which permits one to return futures, closures, and other anonymous types from traits (particularly when combined with generic associated types):

trait Service {
    type Future: Future<Output = Response>;
    
    fn process_request(&self, input: Input) -> Self::Future;
}

impl Service for MyService {
    type Future = impl Future<Output = Response>;
    
    fn process_request(&self, input: Input) -> Self::Future {
        async move { ... }
    }
}

However, this is somewhat unergonomic. I would also prefer to enable users to use impl Trait directly within traits and impls:

trait Service {
    fn process_request(&self, input: Input) -> impl Future<Output = Response>;
}

impl Service for MyService {
    fn process_request(&self, input: Input) -> impl Future<Output = Response> {
        async move { ... }
    }
}

This will be particularly important in order for us to support async fn in traits:

trait Something {
    async fn process_request(&self, input: Input);
}

impl Something for MySomething {
    async fn process_request(&self, input: Input) {
    
    }
}

One challenge is that it is very likely that we will need ways to bound the return type from async fn and -> impl Future methods. For example, it would be useful to be able to say that you have a "service which returns Send futures", which could do today by writing something like:

fn take_service<S: Service>(s: S)
where
    S::Future: Send,
{

}

It would be unfortunate if the friendly form of using impl Trait or async fn in traits were to become an anti-pattern because it limited your consumers. This is particularly true for async fn as the desugaring to impl Trait can be quite tedious to do if there are lifetimes involved.

Goal

The idea is that we would accept syntax like:

trait TheTrait {
    fn the_fn<T>(&self) -> impl Trait;
}

impl TheTrait for SomeType {
    fn the_fn<T>(&self) -> impl Trait { () }
}

Desired semantics

This is meant to be roughly equivalent to a (potentially generic) associated type:

trait TheTrait {
    type TheFn<T>: Trait;
    fn the_fn<T>(&self) -> Self::TheFn<T>;
}

impl TheTrait for SomeType {
    type TheFn<T> = impl Trait;
    fn the_fn<T>(&self) -> Self::Foo<T> { () }
}

Things to figure out

But we need to describe exactly how this works. How…

• can users name the return type of the_fn?
• can users bound the return type of the_fn in where clauses?

Examples

For each solution, my expectation is that the trait and impls look exactly as pictured in the "Goal" above. But we do want to show code that references TheFn. Here is the example code written against the "Desired semantics" version:

fn some_other_fn<T: TheTrait>(t: T)
where
    for<T> T::TheFn<T>: Send
{
    let return_value = t.the_fn::<()>();
    std::thread::spawn(move || {
        // to do this, `return_value: Send` must be true
        drop(return_value);
    })
}

This topic is a brainstorming topic, I just want to get pointers to the range of ideas that are out there.

Questions / (Potential) Constraints

• Should we choose something forward-compatible with a generalization to supporting naming the argument types as well as the return type, rather than giving the return type a special role?
  • (Arguably return types already have a special role; e.g. they are an associated type for the Fn family of types, while the argument types are type parameters for the Fn family of types)
• We have to address dyn safety and the naming of types, but that is at least somewhat orthogonal.

Options

Cramertj's RFC

cramertj penned a draft RFC some time back that permitted:

• impl Trait in trait definitions
  • given a trait using impl Trait, the impl can either use impl Trait notation, use a specific type, or use narrowed types like impl Trait + Trait2
  • however, it is not possible to name the output type of a function in a generic context
• impl Trait in impls as well as inference for the values of associated types

The RFC also addressed issues around dyn safety by making traits using impl Trait not dyn safe.

Examples

The example cannot be written in this style, unless this proposal is combined with one of the alternatives.

Desugar

We could build on cramertj's proposal by saying that a trait with methods which return an impl Trait is desugared to a trait with a named associated type.

• To make this maximally idiomatic, we could convert the method name into CamelCase and make an associated type. If there already is one, it's an error.
  • Note: we do have to decide what to do with underscore-prefixed or Unicode identifiers. We would probably just include prefix underscores, and we would try to use the capitalization rules that unicode gives us, but ultimately fallback to just include characters as is if we can't figure out what to do.
  • We could introduce a lint for cases that don't cleanly convert and encourage folks to make an associated type with a different name.
• **Alternative: Don't convert the name, just introduce an associated type with the same name. Less idiomatic, but not terrible.

Observations

This approach allows interconversion between explicit associated types and functions and makes older traits that do not use impl Trait "fit in" more naturally.

It is rather magical – where does this name come from?

Examples

The example looks example as we described initially.

fn some_other_fn<T: TheTrait>(t: T)
where
    for<'a, T> T::TheFn<'a, T>: Send
{
    let return_value = t.the_fn::<()>();
    std::thread::spawn(move || {
        // to do this, `return_value: Send` must be true
        drop(return_value);
    })
}

Inference scheme examples / thoughts

The inference scheme loosely described above for impls implies that an impl like this might work, because not returns Self::Output so we can infer it from the function declaration:

impl Not for MyType {
    // type Output = SomeOtherType; <-- not needed!

    fn not(self) -> SomeOtherType {
        ...
    }
}

Since impl Trait can appear in non-trivial places, we would probably want to extend it to cases where the associated type is returned directly. This would imply that a case like Iterator should work too:

impl Iterator for MyType {
    // type Item = SomeOtherType; <-- not needed!

    fn next(&self) -> Option<SomeOtherType> {
        ...
    }
}

But we probably do have some limits, have to feel out what those are exactly. This is tied somewhat to implementation: we have to be careful how much "type machinery" we have to bring to bear to do this inference.

Note: cramertj wrote an RFC for this a while ago: here

return keyword

Another option: introduce the F::the_fn::return notation. One thing to consider is that we need generics somewhere in that list, so it might be F::the_fn<...>::return.

Examples

fn some_other_fn<T: TheTrait>(t: T)
where
    for<T> T::the_fn<T>::return: Send
{
    let return_value = t.the_fn::<()>();
    std::thread::spawn(move || {
        // to do this, `return_value: Send` must be true
        drop(return_value);
    })
}

FnType keyword

Another option: introduce a keyword to access the (unnamed) type of current function or closure after all generics substitution, so it might be FnType::Output or <FnType as FnOnce()>::Output.

Observation: a keyword is not really needed, per my notes above. So it might just be T::the_fn<T>::Output? This is appealing. –nikomatsakis

Introduce an associated type for the function type

We could introduce an implicit associated type the_fn for every function. It would resolve to the Fn type of the method itself. This would require an edition to do completely because of namespacing, but we could do it for any function that returns an impl Trait in some form, since that is currently illegal; it'd be an error to do it if there is an associated type already defined with the same name as the method. (In earlier editions, we could introduce some k#foo keyword to access the names for earlier methods.)

Then instead of using ::return you just use ::Output.

There is some interaction with specialization I want to tease out. I think everything is fine with the current design but I do remember discussions about the fact that users could not observe the types for functions directly, though I forget when/where this was significant. I'm also pondering whether we want to offer the ability to access (somehow…) "unspecialized" versions.

Note that this would presumably require you to specify the 'a in the list of generics, even though it's not relevant to the impl trait in the end. This is a downside.

Examples

Note that this would presumably require you to specify the 'a in the list of generics, even though it's not relevant to the impl trait in the end. This is a downside.

fn some_other_fn<T: TheTrait>(t: T)
where
    for<'a, T> T::the_fn<'a, T>::Output: Send
{
    let return_value = t.the_fn::<()>();
    std::thread::spawn(move || {
        // to do this, `return_value: Send` must be true
        drop(return_value);
    })
}

XXX writing an example that shows how you could use the type of the function itself is kind of tedious =)

Introduce typeof

If we added a typeof operator that takes an expression and gets its type, then one could write typeof(T::the_fn::<'a, T>) in place of T::the_fn<'a, T> from the previous section. typeof could be useful in other contexts too, of course.

Examples

fn some_other_fn<T: TheTrait>(t: T)
where
    for<'a, T> typeof(T::the_fn::<'a, T>)::Output: Send
{
    let return_value = t.the_fn::<()>();
    std::thread::spawn(move || {
        // to do this, `return_value: Send` must be true
        drop(return_value);
    })
}