The correct Rust version also looks very much like the idiomatic C++. Iterator invalidation is an annoying problem and is one of the problems that the Rust borrow checker addresses.

It also looks wrong. What happens if two people shoot the same player and the first laser strike kills them? Won’t you now respawn them and then the second laser strike will reduce their health? The correct thing, I would think, would be to collect a map of players to damage, iterate over the players and collect the amount of damage inflicted per player, then iterate over the map and apply that damage to the target.

While I’m a big fan of Rust and the borrow checker, this isn’t necessarily a logic bug. You might have reasonably wanted players earlier in the list to be able to kill players later in the list but not vice versa. Changing your code to satisfy the borrow checker just revealed that you didn’t want the previous behavior.

It’s also actually fairly trivial to satisfy the borrow checker in the original case, precisely because you’re using a sequentially indexed collection. Instead of:

    for (shooter_idx, shooter) in players.iter().enumerate() {
        if shooter.firing {
            for (other_idx, other) in players.iter_mut().enumerate() {

You could have done this:

    for shooter_idx in 0..players.len() {
        if players[shooter_idx].firing {
            for other_idx 0..players.len() {

Then just modify other with players[other_idx] and the borrow checker will happily let you treat both as mutable. I removed the Copy derive which can mask subtle bugs, and changed it to modify both players in the inner loop just to show you can.

It’s not as idiomatic as the iterator solution, but it’s a trivial change that the borrow checker would not have prevented. Just worth keeping in mind because I have seen that kind of code before (and used it myself recently on a few advent of code problems when I didn’t feel like doing things the “right” way….).

What would happen if the code were structured like that, as it would have been if I were using a language without a borrow checker? The player that comes first in the vector kills the player that comes later in the vector. After that, the player who was hit is either dead or has respawned somewhere else, thus he cannot retaliate in the same frame.

This sort of thing is the reason why some games and/or engines defer “destructive” state transitions – not necessarily to the end of the frame, but at the very least to the end of some particular “phase”.

I think the most common example, albeit at a different level and concerning a different kind of destructive state transition, is Unity’s Destroy behaviour. You can destroy an object whenever you want during an update cycle, but the actual destruction is deferred to after the update cycle so that anyone who still holds a reference to that object and needs things from it can still use it.

In this case: the inner collision test loop can avoid handling deaths and respawns immediately. E.g. it could do something like this:

                if other.health <= damage {
                    other.health = 0
                } else {
                    other.health -= 5;
                }

and then, after you’ve processed all relevant state, you start collecting dead players – most trivially with something like this, but obviously if you expect to have hundreds of them you probably want some other way to keep tabs:

for player in players.iter().enumerate() {
    if player.health == 0 {
        // Handle death, schedule respawn etc.
    }
}

(edit: for a cleaner functionally equivalent variant in a modern setting, see this suggestion; my retro platform background is showing at the seams here – if I read about lasers and ships I’m going to write NES code no matter what :-D).

This lets you avoid the extra lasers vector, at least in this restricted case, although I don’t think it helps with the borrow checker :-).

In “meta” terms, both achieve practically the same thing. Reaping and respawning players after the shooting check loop means their state is reliably sampled throughout that loop. Reaping and respawning them inside the loop means you’re messing up with the sampled state while depending on it being constant; saving the lasers state fixes that by keeping a copy of the state subset that you actually need.

Funnily enough, the title led me to believe that this is one of those complaints against the borrow checker that deems it worse than a nuisance. Good to know it’s otherwise :)