Allow unsized closures in iterator adaptors

[bluss]

For example, Map<I, F> can be generalized to Map<I, F: ?Sized>,
which allows for example the type Map<I, FnMut(Foo) -> Bar> as an
iterator.

Generalize filter, filter_map, flat_map, inspect, map, skip_while, take_while
like this.

A struct can only have one unsizeable field, so we have to pick either
unsizing the iterator or closure parameter for all of these, but it
seems right to pick the closure parameter. The whole struct itself can
already coerce to the Iterator type.

Fixes #38133

Extra Remarks

1. My first idea that specialization was required for Map::fold here was
   mistaken (and trying that finds a type inference bug). Instead the remaining
   blemish is that we have to use &mut self.f in Map::fold. The compiler
   doesn't understand that Self: Sized implies F: Sized there.
2. I don't have a particular motivation goal with this change, just was curious
   about this and it is technically correct.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

Thanks for the PR @bluss! This looks pretty nifty to me!

You mentioned though that you don't have any particular motivational goal with this change, and that'd be my next question! This makes sense to me but I'm not really sure how we'd take advantage of it? Do you have some example use cases in mind though?

[nagisa]

I wanted this in something like:

struct MyAdaptor {
    ...,
    inner: Map<::std::iter::Map<::std::ops::Range<u8>, Fn(u8) -> u32>>,
}

where it was fine for MyAdaptor to be ?Sized. I do not remember anymore the exact use case I had for this though, but I do remember being annoyed by this limitation enough to consider filling an issue.

[oli-obk]

couldn't you also just add an F: Sized bound?

[bluss]

Not allowed unfortunately. Doesn't match the trait.

[alexcrichton]

Hm I'm still sort of stuck about what to do for this. This is providing a guarantee in the standard library that we can't ever change. Despite that, though, there's no concrete use cases proposed yet?

[bluss]

I agree with that as a rule of maintainership; no point in merging if it doesn't have its use case clearly described.

The only thing I saw here was the factor of extending the api to the conventions of Rust and internal logic of its type system, and the expectation that we provide as generic items as we practically can.

I can't actually come up with a use case (I'm looking forward to impl Trait!), so it's fine to skip this for that reason.

Regarding @nagisa's example, Rust doesn't in practice allow such a thing verbaitm, since one can't fill the struct field.. it would have to be a type parameter and undergo the unsizing coercion, right?

// Can be cast to `MyAdaptor<Fn(u8) -> u32>`.
struct MyAdaptor<F: ?Sized> {
    ...,
    inner: ::std::iter::Map<::std::ops::Range<u8>, F>,
}

[carols10cents]

ping @alexcrichton, wdyt about the last comment here?

[alexcrichton]

Ah oops sorry. Ok it sounds like this is mostly opportunistic for now and doesn't have a motivating use case, so I'm going to close this. If a use case comes up though please feel free to resubmit!