Patterns for Defensive Programming in Rust
corrode.dev
Patterns for Defensive Programming in Rust
1–10 of 99 posts
Re: Patterns for Defensive Programming in Rust
#2This is one of the best Rust articles I've ever read. It's obviously from experience and covers a lot of _business logic_ foot guns that Rust doesn't typically protect you against without a little bit of careful coding that allows the compiler to help you.
So many rust articles are focused on people doing dark sorcery with "unsafe", and this is just normal every day api design, which is far more practical for most people.
Re: Patterns for Defensive Programming in Rust
#3The very useful TryFrom trait landed only in 1.34, so hopefully the code using unwrap_or_else() in From impl predates that...
Actually the From trait documentation is now extremely clear about when to implement it (https://doc.rust-lang.org/std/convert/trait.From.html#when-t...)
Re: Patterns for Defensive Programming in Rust
#4The very useful TryFrom trait landed only in 1.34, so hopefully the code using unwrap_or_else() in From impl predates that... Actually the From trait documentation is now extremely clear about when to implement it ( https://doc.rust-lang.org/std/convert/trait.From.html#when-t... )
As someone unfamiliar with Rust (yet! it's on my ever growing list of things I'd like to absorb into my brain), unwrap_or_else() sounds like part of the "What You See Is What I Threatened the Computer To Do" paradigm.
Re: Patterns for Defensive Programming in Rust
#5The very useful TryFrom trait landed only in 1.34, so hopefully the code using unwrap_or_else() in From impl predates that... Actually the From trait documentation is now extremely clear about when to implement it ( https://doc.rust-lang.org/std/convert/trait.From.html#when-t... )
As someone unfamiliar with Rust (yet! it's on my ever growing list of things I'd like to absorb into my brain), unwrap_or_else() sounds like part of the "What You See Is What I Threatened the Computer To Do" paradigm.
> INTERCAL has many other features designed to make it even more aesthetically unpleasing to the programmer: it uses statements such as "READ OUT", "IGNORE", "FORGET", and modifiers such as "PLEASE". This last keyword provides two reasons for the program's rejection by the compiler: if "PLEASE" does not appear often enough, the program is considered insufficiently polite, and the error message says this; if it appears too often, the program could be rejected as excessively polite.
Re: Patterns for Defensive Programming in Rust
#6Wow that’s amazing. The partial equality implementation is really surprising.
One question about avoiding boolean parameters, I’ve just been using structs wrapping bools. But you can’t treat them like bools… you have to index into them like wrapper.0.
Is there a way to treat the enum style replacement for bools like normal bools, or is just done with matches! Or match statements?
It’s probably not too important but if we could treat them like normal bools it’d feel nicer.
Re: Patterns for Defensive Programming in Rust
#7Earlier quoted context omitted.
As someone unfamiliar with Rust (yet! it's on my ever growing list of things I'd like to absorb into my brain), unwrap_or_else() sounds like part of the "What You See Is What I Threatened the Computer To Do" paradigm.
> INTERCAL has many other features designed to make it even more aesthetically unpleasing to the programmer: it uses statements such as "READ OUT", "IGNORE", "FORGET", and modifiers such as "PLEASE". This last keyword provides two reasons for the program's rejection by the compiler: if "PLEASE" does not appear often enough, the program is considered insufficiently polite, and the error message says this; if it appear…
Immediately thought of INTERCAL :)
Re: Patterns for Defensive Programming in Rust
#8Loved the article, such a nice read. I am still slowly ramping up my proficiency in Rust and this gave me a lot of things to think through. I particularly enjoyed the temporary mutability pattern, very cool and didn't think about it before!
Re: Patterns for Defensive Programming in Rust
#9Wow that’s amazing. The partial equality implementation is really surprising. One question about avoiding boolean parameters, I’ve just been using structs wrapping bools. But you can’t treat them like bools… you have to index into them like wrapper.0. Is there a way to treat the enum style replacement for bools like normal bools, or is just done with matches! Or match statements? It’s probably not too important but i…
I almost always prefer enums and matches! vs bool parameters.
Another way is to implement a Trait that you find useful that encapsulates the logic. And don't forget you can do impl {} blocks to add useful functions that execute regardless of which member of the enum you got.
enum MyType{
...
}
impl MyType{
pub fn is_useable_in_this_way(&self) -> bool{
// possibly ...
match self {...}
}
}
pub fn use_in_that_way(e: MyType) {
if e.is_useable_in_this_way() {...}
}
if let MyType::Member(x) = e {
...
}Re: Patterns for Defensive Programming in Rust
#10The very useful TryFrom trait landed only in 1.34, so hopefully the code using unwrap_or_else() in From impl predates that... Actually the From trait documentation is now extremely clear about when to implement it ( https://doc.rust-lang.org/std/convert/trait.From.html#when-t... )
As someone unfamiliar with Rust (yet! it's on my ever growing list of things I'd like to absorb into my brain), unwrap_or_else() sounds like part of the "What You See Is What I Threatened the Computer To Do" paradigm.
There are also the equally threatening and useful `map_or_else` (on Result and Option) and `ok_or_else` (on Option and experimentally on bool)