If Range doesn't require PardialOrd, I'm not sure I know what Range is at all...
It does indeed require PartialOrd and the author has already fixed the mistake. But I wonder why PartialOrd is implemented for ().
My least favorite Rust type
271–280 of 298 posts
Re: My least favorite Rust type
#272Earlier quoted context omitted.
I disagree, sometimes you end up building empty ranges in your code for valid reasons (as a result of math, for example). special casing a check on literals feels a bit like saying you can create an empty non-mutable vector.
If I had a need for that I would write a surprised snake (0..0) instead.
Exactly. (5..0) is almost surely a developer that expects the range 5, 4, 3, 2, 1
Re: My least favorite Rust type
#273Earlier quoted context omitted.
If you try to enforce start I mean consider: `slice.get(start..end)` against: `(start..end).and_then(|range| slice.get(range))`
I would even say that it is optimized for the following slice[start.end] particularly because `[]` indexing is already a panicky operation.
Sure, get is like [] but without panic.
I.e. slice.get(5..0) == None
Re: My least favorite Rust type
#274If Range doesn't require PardialOrd, I'm not sure I know what Range is at all...
It does indeed require PartialOrd and the author has already fixed the mistake. But I wonder why PartialOrd is implemented for ().
This is because tuples like `(T, U)` implement `PartialOrd` - this is actually useful. If you are going to implement `PartialOrd` for tuples, it makes sense to implement it for 0-tuple too.
Re: My least favorite Rust type
#275Range's idiosyncrasies and the antipathy to improving its ergonomics manifest in the issues raised against the project have been a capstone mental block to my investing emotionally in Rust. I continuously really want to like the language. The premise is good, a lot of the ideas are really compelling, but when it comes down to aspects I disagree with, I get a strong sense of Rust demanding that users subjugate themsel…
> I get a strong sense of Rust demanding that users subjugate themselves to all the choices and opinions of the architects [..] I don't really get where you're coming from here, especially with regards to this issue -- it seems like almost everyone, including Rust core team members, agree that `impl Iterator for Range` was an API design mistake, that came out of (IIRC) Iterator existing prior to IntoIterator in the p…
>This seems to me to just be an unfixable design flaw due to backwards-compatibility rules
This sounds like something that could be solved in the next edition.
Re: My least favorite Rust type
#276Earlier quoted context omitted.
> I get a strong sense of Rust demanding that users subjugate themselves to all the choices and opinions of the architects I don't know why you feel that way. Any major language or standard library change goes through an RFC process, where anyone in the community can submit feedback, and from what I have seen, the official teams are very responsive to concerns.
There are a few things: - The big one is that, at least what I see from my admittedly flawed perspective, there appears to be an active annoyance by a significant number of participants on the various issues on the importance of maintaining library ergonomics under constrained execution environments, with bare metal / free-standing environments being an obvious scenario. An example that comes to mind being stuff deal…
That last one is a common enough idea nowadays. Prominent people in every community advocate enforcing code style rules (Douglas Crawford's Javascript linter is famous as an early example and gofmt is practically enforced in the community).
The rest of the issues you mentioned are being actively worked on or investigated. Yes Rust 1.0 didn't solve all problems out of the gate and even now there's a lot of work still to do. But a lot of progress has been made and is being made.
I get that if you don't follow issues, working groups, zulip chats, etc that it may not be obvious what is and isn't being worked on but I'm really not sure where you're getting this "arrogance" from.
Re: My least favorite Rust type
#277The worse bug I fought in one of my rust programs was when using the range type. I needed to go from n to 1 included, so, from n included to 0 excluded. Of course `(n..0)` didn't work, so I tried `(0..n).rev()`, which didn't work either (first, you generate all numbers in [0;n-1], then you reverse the list), and I can't blame the language, it makes sense, but it's highly unintuitive (in python for instance, `range(n, 0, -1)` does what is expected).
I'm not a seasoned rust programmer though, is there a better, more explicit way to do what I attempted there?
Re: My least favorite Rust type
#278For literals, clippy will catch this by default: error: this range is empty so it will yield no values --> src/main.rs:2:9 | 2 | let x = 5..0; | ^^^^ | = note: `#[deny(clippy::reversed_empty_ranges)]` on by default = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#reversed_empty_ranges help: consider using the following if you are attempting to iterate over this range in…
This tripped me up a few times in Swift in the beginning, when I did a range `lowerBound .. higherBound`, which can often happen naturally, it would default to the empty range. Still think empty range would be the sensible thing here, but at least Swift throws an exception, so after an initial wtf it wasn't a problem.
Re: My least favorite Rust type
#279The worse bug I fought in one of my rust programs was when using the range type. I needed to go from n to 1 included, so, from n included to 0 excluded. Of course `(n..0)` didn't work, so I tried `(0..n).rev()`, which didn't work either (first, you generate all numbers in [0;n-1], then you reverse the list), and I can't blame the language, it makes sense, but it's highly unintuitive (in python for instance, `range(n,…
I think (1..=n).rev() will do what you want?
A .step_by() that accepts negative values a la python would be nice, but I can live without.
I'd love a REPL for this sort of thing though - a website just isn't as good.
Re: My least favorite Rust type
#280The worse bug I fought in one of my rust programs was when using the range type. I needed to go from n to 1 included, so, from n included to 0 excluded. Of course `(n..0)` didn't work, so I tried `(0..n).rev()`, which didn't work either (first, you generate all numbers in [0;n-1], then you reverse the list), and I can't blame the language, it makes sense, but it's highly unintuitive (in python for instance, `range(n,…
[deleted]