accumulate: can/should it test for mapping to a different type?

[petertseng]

Traditionally map would be (a -> b) -> [a] -> [b], but here we only have (a -> a) -> [a] -> [a] (and in fact we only have i32 anyway). Can/should it test for mapping to a different type?

Note that this would subsume #628 ; you'd not be able to mutate the input if it were a different type, so this could make both proposed changes at once

[Emerentius]

I think this would be a good change. We can ratchet it up through the tests step by step, for example like this:

1. i32 -> i32
   Requires generics, at least Fn(i32) -> i32

2. i64 -> i64
   Generic input / output, requires at least Fn(T) -> T, T: Copy
   but user may still do for &x in input.iter() { ... }

3. &mut i32 -> &mut i32 => Fn(T) -> T
   Or some other Non-Clone type. Force moving.
   for x in input { .. }

4. String -> Vec => Fn(T) -> U
   Differentiate input/output

5. FnMut, closure with mutation.
   Fn is a needlessly high expectation for a function. It just needs to be repeatedly callable.

This simple exercise is hiding a fair amount of complexity if it's fully generalized: Generics, the Fn traits and their differences, IntoIterator and moving in general.

Maybe this is too much at once?

[coriolinus]

Agree that it can and should test mapping to a new type.

Maybe this is too much at once?

No, I really like that test ratchet, @Emerentius.

[coriolinus]

Implemented in #629.