What do we guarantee for `RangeIter::remainder`?

What should RangeIter::remainder do when it came from a non-canonical Range?

For example, range::Range { start: 10, end: 1 }.into_iter().remainder() -- is it required to be 10..1?

Perhaps it should return Option, just like RangeInclusiveIter::remainder. The question then would be whether it should have the same rule, empty gives none, or a more nuanced rule, perhaps only non-canonical ranges give none.

If you iterate from 2..4, stopping at 4..4 (for forward iteration) or 2..2 (for backward iteration) is easy enough to guarantee. But it would be kinda nice to just not have to store 4..2 ever, especially if we could use that to make Option<RangeIter> niche-optimized.

(Said the other way around, if (a..b).into_iter().remainder() has to always be a..b, then we're prevented from ever optimizing the storage to have niches.)

Proposal:

Like RangeInclusiveIter::remainder, we say that RangeIter::remainder returns None if the iterator is exhausted.

That gives us two immediately-possible opportunities:

• Normalize invalid ranges to empty ones in Range::into_iter, since we'll never have to return anything from remainder, and thus can optimize all the methods knowing that start > end is never something to worry about.
• We can let run-to-exhaustion methods leave it in whatever empty iterator state is most convenient, even if it takes &mut.

Nominated because RangeInclusiveIter::remainder hits stable in under a month, so while I don't think this going to impact that, if we did want to tweak it it'd have to be soon.

Start with the linked RangeIter::remainder and RangeInclusiveIter::remainder API entries and compare their documented behavior for exhausted and non-canonical ranges. The issue is done when the remainder guarantee and the proposed Range::into_iter normalization or storage implications have a decided specification.