5 ms·

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 b

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

leshow 6y ago
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?
- andy_ppp 6y ago
  Traverse the entries?
  - dathinab 6y ago
    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 ;=)
  - leshow 6y ago
    we're talking about a range of vec![8,9]..vec![1,2] for example. What does 'traverse the entries' between those two values mean?
- javajosh 6y ago
  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!
  - leshow 6y ago
    The fact that there are options is my point: it's ambiguous. That's the reason there is no implementation for it in the std lib. You're absolutely free in Rust to define your own though.
    - estebank 6y ago
      Step is still unstable but the point still stands.
  - setr 6y ago
    This seems like you'd very quickly end up with a mess of arbitrary heuristics falling over itself with seemingly mundane changes, ala excel
bilkow 6y ago
It looks like you can't. You can create a Range out of it, but the range is not an iterator. If you look at the Range docs[0], you'll see that it only implements Iterator where its generic type (A) implements std::iter::Step. Going to the Step docs[1] you'll see that its only implemented by integer types and char. If Vec implemented Step, you could iterate over it. Also, if you're referring to the "contains" guessing puzzle, you have to look at Range::contains docs to see it uses Vec's PartialOrd implementation (basically comparison), in which docs state its elements are compared lexicographically. Usually in Rust the first thing I'll do when trying to do something very specific (iterate over a Range of Vecs) is try it at the playground (play.rust-lang.org) and/or just look at std docs. [0] https://doc.rust-lang.org/std/ops/struct.Range.html#impl-Iterator https://doc.rust-lang.org/std/ops/struct.Range.html#impl-Ite... [1] https://doc.rust-lang.org/std/iter/trait.Step.html#implementors https://doc.rust-lang.org/std/iter/trait.Step.html#implement...
- andy_ppp 6y ago
  That’s what I did (at repl.it anyway)... how do I print the values in a Range of Vectors?
  - cdirkx 6y ago
    What would you expect those values to be?
  - kibwen 6y ago
    The range doesn't have values. A range defined by Rust has a start point and an end point, and no other semantics. Some additional functions then add behavior if the types contained in the range can be compared via greater-than, etc. Vecs in Rust can be compared if their contents can be compared. For a range of two vecs, foo and bar, to ask if a third vec is "contained" in that range is to ask if it compares greater than foo and less than bar.
    - andy_ppp 6y ago
      Okay thanks for the explanation!
saagarjha 6y ago
PartialOrd for Vec is a lexicographic ordering. Any range with more than one element will have an infinite number of elements in it.
cultureswitch 6y ago
The whole idea of having Ranges of things without an obvious step function seems backwards to me.
- dathinab 6y ago
  You don't really have it. In rust the (useful) trait implementations on `Range<T>` only exist for `T: Step`. Sure you can create other `Range<T>`'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<Vec<Mutex<Rc<String>>>>` 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 <= end not being enforceable at type level as a fallible range constructor would have a horrible UX. - Range<usize> 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...
- leshow 6y ago
  Well, the std lib disagrees with you. In Rust, type definitions tend to be maximally generic and restricted with traits only in their implementation. Have a look at BTreeMap for example: pub struct BTreeMap<K, V> { root: Option<node::Root<K, V>>, length: usize, } The two type parameters are unbounded, this gives flexibility in the implementation because it allows you to define separate `impl` blocks where the bounds are different and more specific to their use case. Have a look, https://doc.rust-lang.org/src/alloc/collections/btree/map.rs.html#140 https://doc.rust-lang.org/src/alloc/collections/btree/map.rs... Sometimes the bounds are just Clone, other times they are more complicated Ord bounds for functions like `get`. This is the way Rust libraries are written, it's very flexible and it's the right choice IMO.
dathinab 6y ago
You can create a Range of nearly anything but that doesn't mean any of the methods/traits useful for a Range are implemented on it. E.g. Iterator is only implemented for things implementing the currently unstable Step trait which for now are mainly integers and char. E.g. only Range<usize> can be used to index/slice things.

leshow 6y ago

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?

andy_ppp 6y ago
Traverse the entries?
- dathinab 6y ago
  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 ;=)
- leshow 6y ago
  we're talking about a range of vec![8,9]..vec![1,2] for example. What does 'traverse the entries' between those two values mean?
javajosh 6y ago
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!
- leshow 6y ago
  The fact that there are options is my point: it's ambiguous. That's the reason there is no implementation for it in the std lib. You're absolutely free in Rust to define your own though.
  - estebank 6y ago
    Step is still unstable but the point still stands.
- setr 6y ago
  This seems like you'd very quickly end up with a mess of arbitrary heuristics falling over itself with seemingly mundane changes, ala excel

bilkow 6y ago

It looks like you can't. You can create a Range out of it, but the range is not an iterator. If you look at the Range docs[0], you'll see that it only implements Iterator where its generic type (A) implements std::iter::Step. Going to the Step docs[1] you'll see that its only implemented by integer types and char. If Vec implemented Step, you could iterate over it. Also, if you're referring to the "contains" guessing puzzle, you have to look at Range::contains docs to see it uses Vec's PartialOrd implementation (basically comparison), in which docs state its elements are compared lexicographically. Usually in Rust the first thing I'll do when trying to do something very specific (iterate over a Range of Vecs) is try it at the playground (play.rust-lang.org) and/or just look at std docs. [0] https://doc.rust-lang.org/std/ops/struct.Range.html#impl-Iterator https://doc.rust-lang.org/std/ops/struct.Range.html#impl-Ite... [1] https://doc.rust-lang.org/std/iter/trait.Step.html#implementors https://doc.rust-lang.org/std/iter/trait.Step.html#implement...

andy_ppp 6y ago
That’s what I did (at repl.it anyway)... how do I print the values in a Range of Vectors?
- cdirkx 6y ago
  What would you expect those values to be?
- kibwen 6y ago
  The range doesn't have values. A range defined by Rust has a start point and an end point, and no other semantics. Some additional functions then add behavior if the types contained in the range can be compared via greater-than, etc. Vecs in Rust can be compared if their contents can be compared. For a range of two vecs, foo and bar, to ask if a third vec is "contained" in that range is to ask if it compares greater than foo and less than bar.
  - andy_ppp 6y ago
    Okay thanks for the explanation!

saagarjha 6y ago

PartialOrd for Vec is a lexicographic ordering. Any range with more than one element will have an infinite number of elements in it.

cultureswitch 6y ago

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

dathinab 6y ago
You don't really have it. In rust the (useful) trait implementations on `Range<T>` only exist for `T: Step`. Sure you can create other `Range<T>`'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<Vec<Mutex<Rc<String>>>>` 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 <= end not being enforceable at type level as a fallible range constructor would have a horrible UX. - Range<usize> 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...
leshow 6y ago
Well, the std lib disagrees with you. In Rust, type definitions tend to be maximally generic and restricted with traits only in their implementation. Have a look at BTreeMap for example: pub struct BTreeMap<K, V> { root: Option<node::Root<K, V>>, length: usize, } The two type parameters are unbounded, this gives flexibility in the implementation because it allows you to define separate `impl` blocks where the bounds are different and more specific to their use case. Have a look, https://doc.rust-lang.org/src/alloc/collections/btree/map.rs.html#140 https://doc.rust-lang.org/src/alloc/collections/btree/map.rs... Sometimes the bounds are just Clone, other times they are more complicated Ord bounds for functions like `get`. This is the way Rust libraries are written, it's very flexible and it's the right choice IMO.

dathinab 6y ago

You can create a Range of nearly anything but that doesn't mean any of the methods/traits useful for a Range are implemented on it. E.g. Iterator is only implemented for things implementing the currently unstable Step trait which for now are mainly integers and char. E.g. only Range<usize> can be used to index/slice things.