6 ms·
>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
by matklad 6y ago
>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 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.
- dathinab 6y agoThe 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)`.
- ridiculous_fish 6y agoAuthor 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.)
- matklad 6y agoAgree 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 :)
- lilyball 6y ago> The problem is that his/her proposal … Please just use the word “their”. “his/her” is not just awkward but also not even inclusive, as there are many people who do not use “his” or “her” pronouns.
- tuesdayrain 6y agoIt's sad how many cumulative hours have been lost to policing language just because some <1% of the population decided to treat their pronouns like a fashion accessory that must be as unique as possible.
- nine_k 6y agoIf it's "his" vs her", the proportion is more like 50% / 50%.
- earthboundkid 6y agoFish aren’t human, so the proper pronoun for ridiculous_fish is “it”.
- wokwokwok 6y agoDo you take joy in starting threads like this? You keep doing it. Just let it go. If you don't like the comment, down vote it. When you reply, you just create an irrelevant pointless subthread that has nothing to do with the actual post. Yes, this applies to the parent comment too... ...but the parent comment wasn't being a dick about it. Your comment is creating a pointless thread and being inflammatory, which is just flat out trolling.
- tuesdayrain 6y agoBasically 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.
- hobby-coder-guy 6y agoOmg