Pour reprendre ce que je disais sur les fonctions en *_or un des exemples que j'avais vu était sur ce type de fonctions:
let file = attributes
.into_iter()
.find(|f| f.name.eq(*filename))
.ok_or(std::io::Error::new(
std::io::ErrorKind::NotFound,
format!("File not found (not in attributs): {}", path.join("/")),
))?;
L'expression passée au ok_or() va être évaluée à chaque fois, y compris quand le résultat était un Ok. Pour s'en prémunir, il vaut mieux par la version ok_or_else qui prend un closure dès que le paramètre d'un ok_or (ou d'un unwrap_or) est non trivial.
Si tu veux t'en convaincre, voici un exemple spécifiquement forgé:
fn main() {
let mut v = vec![];
Some(1).unwrap_or({
v.push("foo");
1
});
Some(1).unwrap_or_else(|| {
v.push("bar");
1
});
println!("{v:?}");
assert_eq!(v, vec!["foo"])
}
[^] # Re: Clippy est un bon début
Posté par YetiBarBar . En réponse au journal PullRequest d'une application en Rust. Évalué à 1.
Pour reprendre ce que je disais sur les fonctions en *_or un des exemples que j'avais vu était sur ce type de fonctions:
let file = attributes
.into_iter()
.find(|f| f.name.eq(*filename))
.ok_or(std::io::Error::new(
std::io::ErrorKind::NotFound,
format!("File not found (not in attributs): {}", path.join("/")),
))?;
L'expression passée au ok_or() va être évaluée à chaque fois, y compris quand le résultat était un
Ok. Pour s'en prémunir, il vaut mieux par la versionok_or_elsequi prend un closure dès que le paramètre d'un ok_or (ou d'un unwrap_or) est non trivial.Si tu veux t'en convaincre, voici un exemple spécifiquement forgé:
fn main() {
let mut v = vec![];
Some(1).unwrap_or({
v.push("foo");
1
});
Some(1).unwrap_or_else(|| {
v.push("bar");
1
});
println!("{v:?}");
assert_eq!(v, vec!["foo"])
}