>This does mean writing for n in (1..10).iter(), but Rust already requires that for collections, so it’s more consistent.
Even this needn't be the case. `Range` can implement `IntoIter` to plug into `for` loop syntax.
Another related problem is that `SliceIndex` (https://doc.rust-lang.org/std/slice/trait.SliceIndex.html) trait, which is used to implement indexing, is perma-unstable. So, even if you build your own better range, you can't make it play nicely with slices.
The problem is that his/her proposal also says that start <= end needs to be enforced (or non of his "faster" things would work).
Now consider the usability nightmare `(1..10).unwrap()` would be and `&slice[(1..10).unwrap()]` and `(1..10).and_then(|range| slice.get(range))` instead of `slice.get(1..10)`.
That's the actual problem, not that `Range` implements iterator.
Oh and most ranges are used ad-hoc (created and then directly consumed) so for many use cases going with Range + IntoIterator would increase the overhead.
Besides that while SliceIndex is perma unstable, `Index` is not so if you control the container you can make it work alternatively you can always do `my_range.index(slice)`.
Author here. In my idea, x..y would be like x+y: not fallible, but may panic. There would be a separate fallible function for creating ranges, analogous to checked_add.
(Of course unlike x+y, x..y would require checks in release builds too.)
Agree with you that there won't be any problems with panicking in this setup.
Although, it'll require some non-minor api adjustments: at the moment, Range's fields are public. To maintain the invariant, we would have to make them private and provide getters. Which we actually already do for RangeInclusive, because of that extra bool field. Which is an inconsistent mess :)
Basically all of your statements apply to your own post. You created a pointless subthread and resorted to direct insults that are far more inflammatory than anything I said.
Even this needn't be the case. `Range` can implement `IntoIter` to plug into `for` loop syntax.
Another related problem is that `SliceIndex` (https://doc.rust-lang.org/std/slice/trait.SliceIndex.html) trait, which is used to implement indexing, is perma-unstable. So, even if you build your own better range, you can't make it play nicely with slices.