---
tags: brainstorming
---

# 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](https://github.com/cramertj/impl-trait-goals/blob/impl-trait-in-traits/0000-impl-trait-in-traits.md) 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](https://github.com/cramertj/impl-trait-goals/blob/impl-trait-in-traits/0000-impl-trait-in-traits.md)

### `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](#Introduce-an-associated-type-for-the-function-type). `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);
    })
}