My least favorite Rust type • Hacker News Board

Re: My least favorite Rust type

#201

Post by ridiculous_fish » Mon, Sep 21, 2020, 10:54 PM UTC

dathinab wrote: post #185

matklad wrote: post #53

>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 b…

The problem is that his/her proposal also says that start 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 + IntoIter…

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.)

Re: My least favorite Rust type

#202

Post by Ygg2 » Mon, Sep 21, 2020, 10:57 PM UTC

ShroudedNight wrote: post #173

Range'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…

Sure. But to solve those idiosyncrasies, you need to abandon backwards compatibility or introduce conflicting syntax.

Re: My least favorite Rust type

#203

Post by dathinab » Mon, Sep 21, 2020, 11:00 PM UTC

andy_ppp wrote: post #178

leshow wrote: post #121

Earlier quoted context omitted.

There are plenty of hurdles in Rust, but I wouldn't call this one of them. What exactly do you expect an Iterator for a range of vectors to do?

Traverse the entries?

It's not a range of an vector but a range which start/end are defined by vectors.

The best thing I can come up with is that such a range defines a path from one tip of a (geomotric) vector to another vector and because vec in rust can have (theoretically) usize elements it's in a usize::MAX dimensional space ;=)

Re: My least favorite Rust type

#204

Post by estebank » Mon, Sep 21, 2020, 11:01 PM UTC

dathinab wrote: post #197

theon144 wrote: post #149

Earlier quoted context omitted.

Exactly my question. >If you try to enforce that start What even is a "range of non-comparable things"? Doesn't the very definition, included in the article, imply an ordering because of the "upper" and "lower" bounds? What on earth is a situation where "upper" is not necessarily greater than "lower"?

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.

Re: My least favorite Rust type

#205

Post by MaulingMonkey » Mon, Sep 21, 2020, 11:01 PM UTC

dathinab wrote: post #190

marshray wrote: post #166

Also, fix the problem that Range can't do .len(): fn main() { let r = 0u64 .. 1; let n = r.len(); | ^^^ method not found in std::ops::Range println!("Hello, world! {}", n); } https://play.rust-lang.org/?version=stable&mode=debug&editio...

Interesting: .len() is not the length of a slice induced by the range or the distance between start and end but instead it's the len method form `ExactSizedIterator`, which in turn is a "special case" of where `Iterator.size_hint()` is known to return a correct value. The thing is `Iterator.size_hint()` does return a size, which is usize. So `Range ` can only implement `ExactSizedIterator` on 64-bit targets, which I…

It is an interesting, awkward edge case. But the utility of a u64 length might be rarer than you think. `Range` will be more common for wrangling memory sizes, and will handle 64-bit sizes on 64-bit targets - so the utility of Range would mainly be for larger-than-address-space sizes, which probably means falliable I/O calls.

I've been considering upstreaming a trait into the read_write_at crate to provide std::io::Result lengths for Mutex / std::fs::File (on platforms where length is available without mutating seek position - such as on windows via file.metadata().map(|m| m.file_size()) per:)

https://doc.rust-lang.org/std/fs/struct.File.html#method.met...

https://doc.rust-lang.org/std/os/windows/fs/trait.MetadataEx...

Context: multithreaded reads of zip archives & https://github.com/vi/read_write_at/issues/1 & https://github.com/MaulingMonkey/vfs-zip

There's a whole slew of u64 offsets and sizes... the occasional subtraction to calculate a maybe-larger-than-memory size doesn't seem like that big a deal. Occasionally there are methods implemented for it - typically named "file_size()" instead of "len()" though.

Re: My least favorite Rust type

#206

Post by tsimionescu » Mon, Sep 21, 2020, 11:04 PM UTC

centimeter wrote: post #171

WhyNott wrote: post #6

I feel like this is an example of what Jonathan Blow calls a "Big Idea" or a "100% solution". His thesis is that when you make a feature of a language too abstract and usable in many different contexts, eventually there will be so many corner cases that the result will almost certainly be clunky and full of footguns. He claims that language designers should aim for "80% solutions" instead, which cover most common usa…

Haskell’s Foldable and Traversable typeclasses represent these use cases, are more general, and have none of the clunky edges mentioned in the article.

But Range is a concrete type, not an interface, right? And most of the discussion here is about the implementation of Range, not about the interface it exposes to users.

Note also that the clone issue and the borrow issue are not applicable to Haskell, and that the performance characteristics of Range may be hard to replicate while implementing Foldable or Traversable.

Re: My least favorite Rust type

#207

Post by dathinab » Mon, Sep 21, 2020, 11:07 PM UTC

cultureswitch wrote: post #184

andy_ppp wrote: post #78

I can’t even figure out how to iterate over a Range of Vectors? iter and collect both don’t exist... Google doesn’t seem helpful either. I don’t know any rust but it seems unforgiving at the first hurdle here :-)

The whole idea of having Ranges of things without an obvious step function seems backwards to me.

You don't really have it.

In rust the (useful) trait implementations on `Range` only exist for `T: Step`.

Sure you can create other `Range`'s but you can't use them for anything useful. (Ok, if they are PartialOrd you still can use `contains` and `is_empty`).

The article makes it look like a lot of problems comes from rust being too generic over the range type but that's not the case (expect for contains requiring a reference, but then BigNum's are a thing too).

I.e. the only reason why you can create a `Range>>>` is because it doesn't hurt anyone to allow me to do so. But I won't be able to use that rang for anything. It won't implement `is_empty`/`contains` nor will it be Iterable. Heck it doesn't even implement `Clone`. But non of the implementations around iterability, is_empty, contains etc. get in practice any problem because of this type being valid.

Instead the mentioned problems come mainly from:

- start - Range if used for indexing treating things like 5..0 as "out of bounds" while for iterating it's just an "empty" sequence (which is not nice but a very reasonable decisions generally improving usability in practice due to how the range types are normally used in rust but confusing for some less common use case).

- The person somehow being hung up on the exact definition of "out of bounds" not being clear enough defined in the function documentation of a experimental nightly API which is perma-unstable, i.e. we are basically speaking about internal (but visible) implementation details of the standard library...

Re: My least favorite Rust type

#208

Post by ridiculous_fish » Mon, Sep 21, 2020, 11:20 PM UTC

CodesInChaos wrote: post #54

Making `InclusiveRange` an iterator (instead of merely an IntoIterator) was definitely a design mistake and `Range` probably shouldn't be one either. Adding a `Copy` constraint seems a bit weird to me, since I expect those borrows (e.g. on `contains`) for consistency with collections. Deriving `Copy` (i.e. implementing it when the index type is `Copy`) should be enough. One small mistake in the article is that you ne…

Thanks, mistake has been fixed.

Re: My least favorite Rust type

#209

Post by TillE » Mon, Sep 21, 2020, 11:41 PM UTC

ShroudedNight wrote: post #173

Range'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 was super excited about the idea of Rust but constantly frustrated trying to use it to write real code.

I've basically decided to stay in my (ever-improving) comfort zone of C++ until Rust gets named/default arguments, which is my arbitrary litmus test for whether it's going to actually be a usable language for me.

Re: My least favorite Rust type

#210

Post by javajosh » Mon, Sep 21, 2020, 11:42 PM UTC

leshow wrote: post #121

andy_ppp wrote: post #78

I can’t even figure out how to iterate over a Range of Vectors? iter and collect both don’t exist... Google doesn’t seem helpful either. I don’t know any rust but it seems unforgiving at the first hurdle here :-)

There are plenty of hurdles in Rust, but I wouldn't call this one of them. What exactly do you expect an Iterator for a range of vectors to do?

Not really a Rust programmer, but I would expect a Range of vectors to operate something like a vector of Ranges. So if you say [0,10]..[20, 30], the length would be twenty, and the elements would be [1,11], [2,12]... Presumably if there was asymmetry in the values like [1,10]..[20, 50] you'd end up with...something? Not really sure what it should be, there are lots of options!