satisfy the borrow checker in this piece of code

[hoary edge]

fn remove_selected(players: &mut Vec<Player>, ids: Vec<String>) {
    let selected_players = select_players(players, ids); // takes a reference
    let selected_players = selected_players
        .into_iter()
        .map(|p| p.name.as_str())
        .enumerate()
        .collect::<Vec<(usize, &str)>>();
    // sort and reverse with pos as key
    for (pos, _) in selected_players {
        players.remove(pos);
    }
}

error[E0502]: cannot borrow `*players` as mutable because it is also borrowed as immutable
   --> src\main.rs:309:21
    |
300 |             let selected_players = select_players(players, ids)?;
    |                                                   ------- immutable borrow occurs here
...
308 |                 for (pos, _) in selected_players {
    |                                 ------------------------ immutable borrow later used here
309 |                     players.remove(pos);
    |                     ^^^^^^^^^^^^^^^^^^^ mutable borrow occurs here

I am trying to remove some indices from a mutable vector, however, I cannot find a way to work around the borrow checker. I really do not need the selected_players to be a view into players, so it can be some seperate, cloned values, but even if I try to clone selected_players or the string slices inside of it, it still doesn't let me remove those positions. I do need those string slices, because I want to print the names of the items that were removed in the terminal.

[fervent portal]

your indices will be off by one the first iteration of the loop, off by two the second, and so on

what's the type of select_players?

if it returns &Player then it's holding references to the contents of players, you can't remove them from the Vec because that would make the references invalid

[warped vapor]

So, overall, you have a vector of usize, and you want to remove all elements from another vector whose position is one of those usizes?

[swift ledge]

doesn't seem like it'll work

removing with a given index will shift the indices of everything else being removed

oh someone already said that

[warped vapor]

Assuming this works (I wrote it on a phone), it should do all in-place without issues

let mut pos = 0;
let mut to_remove = selected.into_iter().peekable();
players.retain(|_| {
  let current = pos;
  pos += 1;
  let Some(rem) = to_remove.peek() else { return true };
  if rem != current { return true }
  to_remove.next();
  false
})

[swift ledge]

any reason not to just use a filter

oh yeah, retain

that also works

[warped vapor]

Filter might honestly be easier to read, this isn't exceedingly pretty

[swift ledge]

avoids a heap allocation

[warped vapor]

That it does

[swift ledge]

not sure it'll work either though

you're peeking the positions one by one and removing them based on that

I guess if the positions are sorted it'll work

[swift ledge]

tbh there's probably a much better way to do this with a hashset

[warped vapor]

Oh yes, I was assuming that, excellent point.

You could sort them, but I agree the choice to use a vec at all is beginning to be sus

[swift ledge]

fn remove_selected(entries: &mut Vec<Player>, ids: HashSet<String>) {
  entries.retain(|p| !ids.contains(&p.name));
}```

might even want to do a HashSet<&str>, since I doubt they need to be owned strings

actually, how are you storing players? maybe they shouldn't even be in a list in the first place, and you can just keep them in a map like HashMap<String, Player>

could even do Arc<str> and store it as a HashMap<Arc<str>, Player> and store it as Arc<str> in Player too so you're not doubling up on allocations

[hoary edge]

That's why I sort and reverse the list of indices

[hoary edge]

Correct

Sorry, ill respond to your help in a while. Something came up

[hoary edge]

Well, its in a vec, because I also need it to be accessible by index. If a an indexable has set exists, I would use it

[swift ledge]

mm

just be careful passing around indices to a list that can be removed from

[hoary edge]

I could do that, but its a really small scale hobby project, so I don't think that is really necessary

It's an audio looper

[warped vapor]

Then you can do the retain solution instead

[warped vapor]

It would generally make the code easier to write

And also faster, but that's secondary

[swift ledge]

microoptimizations are always worth any amount of time and effort

just think about the microseconds you'll save!

[hoary edge]

Are arc str easier than string slices?

[hoary edge]

I don't think this will work, because of the multiple borrow error. The id's aren't actually strings, but rather a list of Selectors, which is an enum. The select_player function borrows the player vec and returns the list of selected players, but it doesn't allow me to then modify the original list of players.

[swift ledge]

I see

[outer valve]

If you're storing them often, probably. It turns a struct with a lifetime into a struct without one, while retaining all of the performance benefits of using a string slice over an owned string (minus the cost of incrementing an atomic usize)

[hoary edge]

Ah, no they're not stored often, only at the start and possibly in this operations, which is not a common one. The size of the vec is also small < 100.

[hoary edge]

I have solved it by using unsafe:

select_players(unsafe { &*(players as *const Vec<Player>) }, ids)?

I just have to print the names before I remove the players

[warped vapor]

Well, you also need to forever ensure as you update the code around this that you don't violate this assumption

Unsafe is best reserved for safely encapsulated modules, not as a workaround in otherwise safe code

I'm not your code reviewer, though, so... Go ahead at your own risk, I guess