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 thread.
View all comments View context
5 points

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.

permalink
report
parent
reply
2 points
*

Is this crazy?

A general repeat macro that works on stable Rust would work too of course.

permalink
report
parent
reply
2 points

Yeah that’s pretty unreadable IMO. I think your second link isn’t what you intended?

permalink
report
parent
reply
2 points

I think your second link isn’t what you intended?

You scared me for a moment there. I don’t know why you thought that.

Needless to say, even with the first example, metavar expressions are not strictly needed here, as using a second pattern and recursing expansions would work.

But I wanted to showcase the power of ${ignore}, as it can be cleaner and/or more powerful in some cases where extra patterns and recursing expansions can get messy and hard to track.

permalink
report
parent
reply
6 points
*

This is entering subjective taste, but in my opinion this also is a feature of Rust. Especially when the closures are more complicated, it may be not as obvious if and where they are changing state (the fact that Rust implicitely mutably borrows the variables to the closures doesn’t help either).

So a solution of this issue for me would be to add the changed variables as parameters to the closures and explicitely mutably borrow them at the calls in the loop: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=78cc7947e2e0b07b54baf6e1a75a2632

I would agree with you that this increases code verbosity. However, this would be a price I’m willing to pay to help understand at quicker glances what happens inside this loop.

permalink
report
parent
reply
2 points

@Jenztsch @FizzyOrange it would be nice if rust had a feature like inline macros for this kind of behavior just for reducing duplications when you don’t need to capture values as part of a closure.

permalink
report
parent
reply
1 point

I dunno, does it even need a new feature? Kind of feels like Rust should be able to figure it out as long as the lambdas aren’t moved/stored/etc?

permalink
report
parent
reply
2 points
*

@Jenztsch @FizzyOrange

Eg

fn foo() -\> Vec\<i32\> {  
 let mut out = Vec::new();  
 macro! bar(i: i32) {  
 out.push(i);  
 }

 for i in 1..10 {  
 bar!(i);  
 }

 out  
}  
permalink
report
parent
reply
1 point

@FizzyOrange I see what you mean

permalink
report
parent
reply

Rust

!rust@programming.dev

Create post

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)

Community stats

  • 444

    Monthly active users

  • 840

    Posts

  • 3.9K

    Comments