Allow explicitly expressing the type of a -> impl Trait

[tomaka]

Right now, you can do this:

fn foo() -> impl Trait {
    ...   // the return value must implement Trait
}

In this issue I suggest that we add this syntax as well:

type FooRet = impl Trait;

fn foo() -> FooRet {
    ...   // the return value must implement Trait
}

This means that later we can use FooRet to designate the type that foo() returns.
This makes it possible to put it in a struct for example:

struct Bar {
    foo: FooRet,
}

impl Bar {
    fn new() -> Bar {
        Bar { foo: foo() }
    }
}

Unresolved questions

• Do we allow multiple functions to return the same "type=impl type" if their effective return type is the same?
• Handling template parameters looks straight-forward (type Foo<R> = impl Trait; fn foo<R>() -> Foo<R>), but I'm not totally sure that there's a not problem with that.

Alternatives

• Add a syntax that resolves the return type of a function, similar to C++'s decltype.

Motivation

While the feature itself is -I think- mostly straight-forward, the biggest debate is probably the motivation.

Let's take this code:

struct MyIterator { ... }
impl Iterator for MyIterator { ... }

fn get_my_iterator() -> MyIterator { ... }

Right now you can wrap around it, if you want:

struct Wrapper(MyIterator);
fn get_wrapper() -> Wrapper { Wrapper(get_my_iterator() }

This is a zero-cost abstraction and a good usage of composition.

The problem begins when you want to use -> impl Trait:

fn get_my_iterator() -> impl Iterator { ... }

Suddenly, wrapping around it becomes hacky. The primary way to do so is this:

struct Wrapper<I>(I) where I: Iterator;
fn get_wrapper() -> Wrapper<impl Iterator> { Wrapper(get_my_iterator()) }

(The alternative way is to create a new trait named TraitForWrapper which contains the API of Wrapper, and make get_wrapper() return -> impl TraitForWrapper)

This not only complicates the documentation and makes the usage of get_wrapper() more confusing for beginners, but it is also leaky, as it makes wrapping around Wrapper more complicated:

struct WrapperWrapper<I>(Wrapper<I>) where I: Iterator;
fn get_wrapper_wrapper() -> WrapperWrapper<impl Iterator> { WrapperWrapper(get_wrapper()) }

(using the TraitForWrapper method is not better)

This looks like an hypothetical example, but for example if I were to use -> impl Trait in my project, some equivalents to WrapperWrapper would look nightmarish:

struct RenderSystem<Rp1, Rp2, Rp3, Pl1, Pl2, Pl3> {
    fog_of_war_pipeline: GraphicsPipeline<SimpleVertexDefinition, Pl1, Rp1>,
    background_pipeline: GraphicsPipeline<SimpleVertexDefinition, Pl2, Rp2>,
    lighting_pipeline: GraphicsPipeline<SimpleVertexDefinition, Pl3, Rp3>,
}

Basically, the problem of the -> impl Trait syntax is that it's poisonous. Once you use it in an API, all the codes that use this API will have to use -> impl Trait as well.

This proposition would fix this problem:

type MyIterator = impl Iterator;
fn get_my_iterator() -> MyIterator { ... }

struct Wrapper(MyIterator);
fn get_wrapper() -> Wrapper { Wrapper(get_my_iterator()) }

struct WrapperWrapper(Wrapper);
fn get_wrapper_wrapper() -> WrapperWrapper { WrapperWrapper(get_wrapper()) }

[tomaka]

cc @eddyb

[eddyb]

My prototype from last year supported impl Trait in associated types (not included in #1522), e.g.:

impl Iterator for Foo {
    type Item = impl Iterator<Item=String>;
    fn next(&mut self) -> Option<Self::Item> {...}
}

This feature is the minimal extension of #1522 to allow naming impl Trait (i.e. you can always use it to provide top-level type aliases) and it supports all trait usecases that don't involve HKT.

IMO it's a better first step because it's smaller in scope: I side-stepped the problem of choosing which functions to give the ability to determine the impl Trait, by allowing any method in the impl to specify the associated type in its return type, and they had to agree without seeing each-other's choices.

cc @rust-lang/lang

[durka]

I still would like to name the type in the function signature, so it'd be foo::Output or fn foo()<R> -> R and foo::R or something.

[Ericson2314]

I think this would be better served by abstract type Foo = _ and @eddyb's "independent agreement" approach rather than unification.

[eddyb]

@durka We already have syntax for it: <typeof foo>::Output - we just need someone to RFC typeof.

[eddyb]

@Ericson2314 I don't see how the proposal goes against my model, the difference with abstract type seems to be strictly syntactical, i.e. impl Trait is more palatable.
Even type Foo; or type Foo: Bar; is nicer and mimics the existing associated type syntax, while abstract doesn't say anything interesting or relevant (since associated types don't also use it).

[Ericson2314]

@eddyb going back to #105 (comment) I've wanted to separate the inference and abstraction aspects of impl trait. The only reason to keep them separate is avoiding global inference, but as you point out that's actually not necessary.

Because impls are similar to (parametertized) modules, it makes sense to put abstract type in an impl. The semantics are exactly what you say---items in the impl see the real definition but consumers see an abstract type. Similarly, for any item where is concrete, _ instructs that item to infer the type on its own, and only afterwards are the inferred types compared.

[cristicbz]

What are gotchas around <typeof foo>::Output?

Seems like a more general solution (since you can express original using it) and it applies to more cases eg. where a 3rd party library didn't think it was worth exposing the return type as a type alias. I find it very appealing.

[eddyb]

@cristicbz It's not a silver bullet because it gives you the whole type, being able to name an impl Trait is more powerful in that you could have several of them at different levels.
However, I do agree that the ability to later name complex and/or anonymous types is good to have.

EDIT: As for gotchas, typeof $expr is not guaranteed to match another copy of typeof $expr.
That is, typeof || {} is different from any typeof || {} other than itself.
It also needs to be isolated wrt inference, so typeof 0 will be i32 (expect maybe in functions?).

The only new thing as far as the implementation is concerned is being able to type-check and infer that expression passed to typeof on-demand, potentially before the items it depends on even have types.
However, this is already needed for constants so work is underway to support that mechanism.

[tomaka]

There are two possibilities for typeof: either typeof $ident or typeof $expr.
For the former, you'd write something like <typeof foo as Fn>::Output, and for the latter something like typeof foo().

[eddyb]

@tomaka Well, it'd have to be a path not an identifier. But yeah, and it could've been implemented in 1.0.
Keep in mind however that even with the expression form you wouldn't want a call if you have arguments.

[nikomatsakis]

More generally, you would probably write <typeof(foo::<X,Y,Z>) as Fn>::Output or something like that. (Presuming you had fn foo<A,B,C>() { ... }.)