Another crazy idea I share with this website.
I was developing a game and an engine in Rust, so I was reading many articles, most of which criticize the 'borrow checker'.
I know that Rust is a big agenda language, and the extreme 'borrow checker' shows that, but if it weren't for the checker, Rust would be a straight-up better C++ for Game development, so I thought: "Why not just use unsafe
?", but the truth is: unsafe
is not ergonomic, and so is Refcell<T>
so after thinking for a bit, I came up with this pattern:
let mut enemies = if cfg!(debug_assertions) {
// We use `expect()` in debug mode as a layer of safety in order
// to detect any possibility of undefined bahavior.
enemies.expect("*message*");
} else {
// SAFETY: The `if` statement (if self.body.overlaps...) must
// run only once, and it is the only thing that can make
// `self.enemies == None`.
unsafe { enemies.unwrap_unchecked() }
};
You can also use the same pattern to create a RefCell<T>
clone that only does its checks in 'debug' mode, but I didn't test that; it's too much of an investment until I get feedback for the idea.
This has several benefits:
1 - No performance drawbacks, the compiler optimizes away the if
statement if opt-level
is 1 or more. (source: Compiler Explorer)
2 - It's as safe as expect()
for all practical use cases, since you'll run the game in debug mode 1000s of times, and you'll know it doesn't produce Undefined Behavior
If it doesn't crash.
You can also wrap it in a "safe" API for convenience:
// The 'U' stands for 'unsafe'.
pub trait UnwrapUExt {
type Target;
fn unwrap_u(self) -> Self::Target;
}
impl<T> UnwrapUExt for Option<T> {
type Target = T;
fn unwrap_u(self) -> Self::Target {
if cfg!(debug_assertions) {
self.unwrap()
} else {
unsafe { self.unwrap_unchecked() }
}
}
}
I imagine you can do many cool things with these probably-safe APIs, an example of which is macroquad's possibly unsound usage of get_context()
to acquire a static mut
variable.
Game development is a risky business, and while borrow-checking by default is nice, just like immutability-by-default, we shouldn't feel bad about disabling it, as forcing it upon ourselves is like forcing immutability, just like Haskell does, and while it has 100% side-effect safety, you don't use much software that's written in Haskell, do you?
Conclusion: we shouldn't fear unsafe
even when it's probably unsafe, and we must remember that we're programming a computer, a machine built upon chaotic mutable state, and that our languages are but an abstraction around assembly.
I disagree. It's a sign your code isn't structured in a way that the borrow checker understands, but that is a subset of well-structured code.
In other words, if your code nicely fits with the borrow checker then it's likely well structured, but the inverse is not necessarily true.
One thing I always run into is using lambdas to reduce code duplication within a function. For example writing a RLE encoder:
This is a pretty common pattern where you have a "pending" thing and need to resolve it in the loop and after the loop. In C++ you can easily use lambdas like this to avoid duplication.
Doesn't work in Rust though even though it's totally fine, because the borrow checker isn't smart enough. Instead I always end up defining inline functions and explicitly passing the parameters (
&mut out
) in. It's much less ergonomic.(If anyone has any better ideas how to solve this problem btw I'm all ears - I've never heard anyone even mention this issue in Rust.)
@FizzyOrange @savvywolf
I think this is a fine pattern and I use it in rust occasionally.
how does this not work for you?
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0f06fe574e1c69424b4749ef910a1fa7
Sorry that example was a bit too limited to demonstrate the problem actually. Add a second lambda and you hit the issue:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=eb99d3d670bdd9d92006f4672444d611
Still totally fine from a safety point of view, but the borrow checker can't figure that out.
@FizzyOrange I see what you mean