The example even used unwrap_or_else where they should use unwrap_or. Then it uses std::i64::MIN as fallback value where they could use something like 0 that would be a better example and honestly make more sense there.
let parsed_numbers = ["1", "not a number", "3"]
.iter()
.map(|n| n.parse().unwrap_or(0))
.collect();
// prints "[1, 0, 3]"println!("{:?}", parsed_numbers);
Even without trimming this to something less convoluted, the same functionality (with different fallback value) could be written in more readable form.
Obviously in the context of the page something like this would make way more sense:
The example even used unwrap_or_else where they should use unwrap_or. Then it uses
std::i64::MINas fallback value where they could use something like0that would be a better example and honestly make more sense there.let parsed_numbers = ["1", "not a number", "3"] .iter() .map(|n| n.parse().unwrap_or(0)) .collect(); // prints "[1, 0, 3]" println!("{:?}", parsed_numbers);Even without trimming this to something less convoluted, the same functionality (with different fallback value) could be written in more readable form.
Obviously in the context of the page something like this would make way more sense:
maybe_number.unwrap_or(0)Or perhaps more idiomatic version of the above:
maybe_number.unwrap_or_default()I think you could even get rid of the
iter()and thecollect()since it’s a small fixed size array.Yep
[T;N]has a direct implementation ofmap."{:?}"is necessary because arrays aren’tDisplaybut you could get around that by saying["1", "not a number", "3"].map(|n| println!("{}", n.parse().unwrap_or(0)));but now I’m golfing. Also
for n in ["1", "not a number", "3"] { println!("{}", n.parse().unwrap_or(0)) }is more idiomatic I shouldn’t let my Haskell get the better of me. That does use
Iterator, not that it makes a difference here.