F64 collections FromIterator



have been programming rust for three days now: excellent stuff :thumbsup:

I’m trying to get similar functionality to the following C++ code:

std::algorithm::copy(double_c.begin(), double_c.end(), int_c.begin());


std::numeric::iota(double_c.begin(), double_c.end(), 17);

In Rust I was trying variants of

double_c = (17..double_c.len()).map(|x| x as f64).collect();
but `rustc` is giving me `FromIterator<i32>` trait not satisfied for `f64` collections. Is there a way to get this working ad hoc? (without implementing `FromIterator<i32>`)

Thanks for any help

PS/Rant: Shouldn't this have a default implementation? (I mean, it's just casting  i32 to f64, which doesn't lose any accuracy).


Apparently I din’t get closures’ syntax the first time…This solves it:

double_c = (17..double_c.len()).map(|x| {x as f64}).collect();

Moving along now… with lesson learned!


That can’t be all there is to it; closures consisting of a single expression do not require braces. (as a general rule of thumb, they require braces if and only if they contain a semicolon, as this is what marks the difference between a statement and an expression).

fn main() {
    let vec: Vec<f64> = (0..20).map(|x| {x as f64}).collect();
    println!("{:?}", vec);
    let vec: Vec<f64> = (0..20).map(|x| x as f64).collect();
    println!("{:?}", vec);
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
Program ended.

Playpen: https://is.gd/rRp4MC

To be honest your original sample looked valid as written; or rather, even without knowing the type of double_c I cannot picture any circumstance in which it would produce that error message.

(the overall form of the assignment is nonsensical though because it appears to both read from the object as well as bind to it; but I’ll assume that’s an artefact of just writing up an example on the spot)

P.S. It does not seem the C++ code and Rust code is equivalent; the second number in a Rust range is the (exclusive) upper limit, not the length. You may have meant to write (17..17+double_c.len())?


Thanks ExpHP, you’re absolutely rigth on every point :thumbsup:.
If it helps anyone, I think the original error came from trying to reassign slices like this

   let vec = [0; 20];
   vec = (0..20).map(|x| x as f64).collect();