The original example was doing the unwrap_within an iterator doing some string parsing, so there was a lot of unrelated boilerplate around the actual unwrapping that made it really unclear, as well as usual unwrap_or_else to produce a constant value
Ehhh, I was more using get_default as a placeholder for some function, as opposed to representing Default::default for the inner type specifically. I think it should be alright since only people familiar with rust would know about the default trait anyway. I did consider adding an unwrap_or_default example, but thought it was getting a bit off topic at that point.
Rust: here is an array of strings, we are going to parse the array to numbers. If that conversion fails we handle the exception and return the minimum integer value. We then save the result in a new vector. We also print it.
I like rust, but I hate the example too. It’s needlessly complex. Should have just been a.unwrap_or(b).
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 Option type would have been a better example, and make it slightly less complicated.
Option is an enum with two variants; None and Some(T). You can chain Options with operations, describing a Monad chain, which is kind of what this meme represent.
There’s a nice list of this feature by language on the Wikipedia page for anyone interested: https://en.wikipedia.org/wiki/Null_coalescing_operator#Examples_by_languages
This was my first time actually seeing a Rust example, and I hate it.
You’ll be happy to hear I’ve updated the example to be not bad
I wanted to ask why it’s bad, what did you change?
Btw. the example function get_default is badly chosen, because unwrap_or_default exists.
The original example was doing the unwrap_within an iterator doing some string parsing, so there was a lot of unrelated boilerplate around the actual unwrapping that made it really unclear, as well as usual unwrap_or_else to produce a constant value
Ehhh, I was more using get_default as a placeholder for some function, as opposed to representing Default::default for the inner type specifically. I think it should be alright since only people familiar with rust would know about the default trait anyway. I did consider adding an unwrap_or_default example, but thought it was getting a bit off topic at that point.
Yeah I get it, it was just something I noticed. A pedantic lint, you could say.
Ayyyyy
https://en.m.wikipedia.org/wiki/Special:MobileDiff/1189044291
Other languages: if a is null return b.
Rust: here is an array of strings, we are going to parse the array to numbers. If that conversion fails we handle the exception and return the minimum integer value. We then save the result in a new vector. We also print it.
I like rust, but I hate the example too. It’s needlessly complex. Should have just been a.unwrap_or(b).
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.The Option type would have been a better example, and make it slightly less complicated.
Option is an enum with two variants; None and Some(T). You can chain Options with operations, describing a Monad chain, which is kind of what this meme represent.
Damn, they really just made that example as ugly as possible huh