iter: decide on the fate of to_owned_vec, sum and product

[thestinger]

The sum and product methods are wrappers around fold, but only work with iterators where the element type A directly implements Add<A, A>/Mul<A, A>. With an iterator of references to numbers, you can do iter().fold(0, |a, b| a + *b), but with sum/product the elements have to be cloned via map (inefficient for big integers, and uglier than using fold).

The to_owned_vec method simply calls collect, and removes the need to specify a type annotation. It's the only method on iterators using a specific container type, which is ugly. A language solution to this problem (partial type hints? collect::<~[_]>()) would be nice.

These are good candidates for being marked with a stability warning attribute.

[huonw]

(Unfortunately marking them with a stability is blocked on #8961.)

[bluss]

I'm not sure if it's a solution if .to_owned_vec() is made redundant by collect::<~[_]>() Each of those punctuation symbols cost twice-or-more as much to process or type out compared to the characters in .to_owned_vec().

I think the specialized method is the pragmatic solution, but would it be wrong to look towards something completely different? Say standardizing on ::from to create containers from iterators (Iterables?): HashMap::from(v.move_iter()), std::vec::from(range(..).map(..))

[Kimundi]

@blake2-ppc That's basically FromIterator, with which collect is implemented.

Also, I personally find i much harder to parse nested function calls like that than to chain a method, so I'd be against removing that in general.

to_owned_vec is convenient for the reasons lined out by you, but it probably should not life in Iterator. Make it an extension trait for Iterators and stuff it into std::vec.

[thestinger]

@blake2-ppc: It's an extra redundant method for every container to implement and only libstd has the hack of including traits in prelude available.

I'm strongly against including these methods, and also strongly against duplicating trait static methods in the type namespace. Working around language flaws by adding duplicate functions/methods all over the place is awful. I almost regret adding the collect wrapper itself because it set a very bad precedent.

[bluss]

What would the alternative to .collect() be? Could we like my suggestion, have types implement constructor functions with a ::from() convention: HashMap::from(iter), RingBuf::from(iter)

A thought: A trait doesn't have to be a user-facing interface and vice versa. ::new() is a convention but it's an important one, ::from() could be the same.

[thestinger]

collect is implemented on top of the FromIterator trait. It's sugar to work around the pain of using generic static methods, and the lack of type namespaces for built-in types.

Generic conversion from iterators is important, and I am definitely against the usual pattern of duplicating code everywhere.

[bluss]

oh yeah. In my mind FromIterator was just the mechanism to implement .collect(). I assumed you wanted an alternative to both, I don't propose duplicating code. Of course FromIterator::from_iterator is a bit inconvenient to type.

[thestinger]

Yeah, I expect collect to stay around as a necessary evil.

[thestinger]

I'm okay with keeping sum and product around. We can implement Add and Mul for references to deal with the annoyance. The to_owned_vec method will be removed.