Range* should overrride more methods of Iterator

[malbarbo]

Like nth, last, count, max, min,... maybe even sum and product (using a direct formula).

[tvladyslav]

I don't see the use case for nth, last, max, min. Sum and product might be good to have. I'll try to implement them.

[malbarbo]

@crypto-universe The use case is in generic code. Sometimes a range is used in generic code that use these methods, it they are implemented efficiently it is better.

[Mark-Simulacrum]

All ranges that can provide iterator implementations do so today; this excludes RangeFull, RangeTo, and RangeToInclusive. However, these don't make sense as iterators (all don't have start points). As such, I'm closing.

[malbarbo]

@Mark-Simulacrum This issue is about overriding methods of the iterator trait. For example, max can be implemented efficient for Range, but it is not, it uses the default implementation.

[Mark-Simulacrum]

Oh, I misinterpreted then. Reopening.

[SimonSapin]

This is more important now that #41439 deperecated Range::step_by in favor of Iteartor::step_by, and the later returns an iterator wrapper that calls Iterator::nth on its inner iterator.

CC @ivandardi, @BurntSushi, @alexcrichton, @nagisa

[SimonSapin]

#43077 does nth.