Make the return type of Fn trait an associated type

[nikomatsakis]

Fixes #20871

r? @aturon (at least until we decide definitively if this is a good idea)

[alexcrichton]

In terms of the sugar, does this limit us to the possibilities of the Trait(A, B) -> C desugaring later? It kinda semantically makes sense to me that the inputs are type parameters and the output is an associated type, but it seems like our desugaring would look like:

where F: A(B) -> C
// equivalent to
where F: A<B, FirstAssociatedType=C>

which is a little odd, but perhaps not the end of the world!

[sfackler]

Tidy failure https://travis-ci.org/rust-lang/rust/builds/46746709

[nikomatsakis]

@alexcrichton that is precisely what the desugaring amounts to in this version. The fact that Fn(A) -> B desugars to Fn<(A,), Output=B> doesn't seem particularly odd to me by itself (but read on). @eddyb even had the interesting idea that we could extend the ->T sugar to always mean Output=T so that one could write Add<R> -> S instead of Add<R, Output=S>.

There is however one thing I wasn't crazy about: sometimes you won't want to constrain the output of the function. In that case, the existing desugaring doesn't give you that option, so you have to opt out of the sugar altogether.

For example, the Map adapter is written today:

struct Map<A,B,I,F>
    where I : Iterator<Item=A>, F : FnMut(A) -> B
{
    iter: I,
    fn: F
}

impl<A,B,I,F> Iterator<B> for Map<I,F>
    where I : Iterator<Item=A>, F : FnMut(A) -> B
{ ... }

Under this scheme it could be simplified to:

struct Map<I,F>
    where I : Iterator, F : FnMut<(I::Item,)>
{
    iter: I,
    fn: F
}

impl<I,F> Iterator<F::Output> for Map<I,F>
    where I : Iterator, F : FnMut<(I::Item,)>
{
}

I definitely like having fewer type parameters, but the difference between FnMut(I::Item) and FnMut<(I::Item),> feels...subtle. But at the same time having FnMut(I::Item) not bind the result type seems like a non-starter, too inconsistent with other things (and in particular it'd bite us in object type syntax: Box<FnMut()> would be an error, since the Output type is not bound).

On the other hand, if one preferred, one could never use the non-sugared form, at the cost of more type parameters:

struct Map<B,I,F>
    where I : Iterator, F : FnMut(I::Item) -> B
...

so in some sense it's no worse than today, just gives you the option to do better.

[alexcrichton]

Whoa! That is very interesting about the difference between Fn<(Foo,)> and Fn(Foo), I had to read this a few times before it clicked.

For now we don't even necessarily have to have all the parameters on Map, we could just remove the where clause and then add the type parameters to the impl blocks I think?

[nikomatsakis]

@alexcrichton yes, we could.

[nikomatsakis]

I've decided to open an RFC for this. Better to err on the side of more RFCs, I figure.

[nikomatsakis]

@alexcrichton in fact we cannot remove the parameters on map today, due to the fact that B parameter in the impl would be unconstrained, precisely because the return type of the Fn trait is not an associated type.

[nikomatsakis]

RFC has landed now. Rebased, testing the build now. I had to add a fix for #21664 (which is now at the front of the PR series) because recent changes exposed that problem when combined with this change.

[nikomatsakis]

r? @nick29581 (@aturon felt he wasn't familiar enough with the code in question)

[nrc]

@bors: r+ 6734e6305d8abb9f1d51a92fcda1151dafe0fb7f

[bors]

☔ Merge conflict

[nikomatsakis]

@bors r=nrc aaf3df3

[bors]

⌛ Testing commit aaf3df3 with merge f7f9c38...

[nikomatsakis]

@bors r=nrc 05ffdc5

[bors]

⌛ Testing commit 05ffdc5 with merge a45e117...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt

[brson]

breaking change