this post was submitted on 08 Dec 2023
624 points (96.6% liked)

Programmer Humor

32566 readers
283 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
[email protected]
[email protected]
624
know the features of your language (lemmy.world)
submitted 11 months ago by jroid8 to c/[email protected]
144 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 5 points 11 months ago* (last edited 11 months ago) (2 children)

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.

[–] [email protected] 11 points 11 months ago (1 children)

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.

[–] [email protected] 4 points 11 months ago (1 children)

Yeah I get it, it was just something I noticed. A pedantic lint, you could say.

[–] [email protected] 1 points 11 months ago

Ayyyyy

[–] meliaesc 3 points 11 months ago (1 children)
[–] [email protected] 1 points 11 months ago* (last edited 11 months ago) 
 .map(|n| n.parse().unwrap_or_else(|_| std::i64::MIN))

*shudder*

unwrap_or_else and passing a closure that ignores its argument is a definitive smell. Probably gets caught by clippy.