8
submitted 3 months ago by Doods@infosec.pub to c/rust@programming.dev

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.

you are viewing a single comment's thread
view the rest of the comments
[-] Jenztsch@discuss.tchncs.de 3 points 3 months ago

I'm not sure how you intend to use this. When no variables are captured, the borrow checker will not have any issues with the closure method.

When you are still capturing, you could implement a macro like one answer suggests. However, IMO this highly depends on the complexity of the duplicated code and even then I don't immediately see what the benefits compared to extracting it as a closure/function are.

[-] FizzyOrange@programming.dev 1 points 3 months ago

The benefits are that you don't have to pass out and similar captured variables into the closures/functions.

[-] Jenztsch@discuss.tchncs.de 1 points 3 months ago

Then I think RefCell is exactly what you want to defer the mutable borrow to runtime instead of compile time: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3170c01849dc577a501ecb11dd44c5ba (source for this method on StackOverflow).

Maybe there could be syntactic sugar to use captures implicitely as RefCells inside a closure. But I would not be a fan of implicitely allowing multiple mutable borrows without any clue for that in the code.

[-] FizzyOrange@programming.dev 1 points 3 months ago

Not really because RefCell has performance implications and also adds noise to the code.

But I would not be a fan of implicitely allowing multiple mutable borrows without any clue for that in the code.

Nobody is suggesting breaking Rust's multiple mutable borrow restriction. The macro solution simply doesn't do that, and the "make the borrow checker smarter" solution just releases the mutable borrows when they aren't being used so they don't overlap.

this post was submitted on 17 Aug 2024
8 points (72.2% liked)

Rust

6055 readers
91 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS