I've been working on a platformer game in rust. Game objects are stored in a Vec, and each is updated independently. However, a given object would like to interact with other objects. In C I would do something like fn update(&mut self, others: &mut [Self]). However, this would result in the parameters being aliased, which is not allowed.

What I'm looking for is some type that acts like a &mut [T], but remembers which element it is not allowed to access. I could use two &mut [T] values, built with split_at_mut, but this is unwieldy. I could make a struct that contains both. Is there a crate that does this? Ideally it would use unsafe internally so the compiler knows there is exactly one element in between. (that is to say, I would prefer something using only 24 bytes)

Chain does not do what I want because it can only be used as an iterator, not for indexing. To be clear, I would like to be able to index the result exactly like a &mut [T], except that it will find the element under consideration to be out of range.

you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 4 days ago* (1 child)

What are the conditions for T to be accessed? You could potentially wrap each instance of T in an enum that has two states, Allow and Deny, where if you encounter a Deny you just don't access that one. If you have a slice of this enum where each enum owns T, you can always just swap out a Deny for an Allow or vice versa depending on how you want to do it. If you go this route, you might want to make a struct that owns the vector mutably, can return an immutable borrow to the slice, and change permissions on the slice. Now that I'm thinking about it, you can also implement a gets function on the struct that would return a Result depending on whether it was an allow or a deny. I don't think you'd need unsafe with this.

The solution mostly depends on the context surrounding how you're managing what can access T and at what time. I can see the solution I proposed not working if you need more specific permissions than allow or deny, or if the permissions are based on the caller.

Edit: I'm going to come back in a few hours and write code about what I mean in the first paragraph.

  • source
  • hideshow 2 child comments
  • [–] 2 points 3 days ago* (1 child)

    Finally got around to writing the code, here's the link to the Rust playground with it. I was too lazy to do the unsafe stuff, but where I call clone in the deny and accept functions are where you'd rewrite and do unsafe magic to swap out elements without the clone overhead.

    I also tried to implement a take function (like in Option) for the Allowable enum. Transferring ownership like with take would keep you in safe land and get what you want done.

    Keep in mind I am not a game dev. I don't do cache optimizations. I have no idea how this code would function in a game context, but this is just my first idea for implementation of what you asked.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 days ago (1 child)

    Using cells in your solution is smelly, when you can simply use two transparent wrappers with Ref or RefMut access, so you have actual compile-time checking instead of janky checking at runtime (which is also not zero-cost).

    The allow/deny variants could themselves hold & or &mut references too if we are going with that route. But it all depends on the precise problem OP is having and what is the best workable solution for it looks like.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 days ago (1 child)

    How is it a code smell? I'm pretty sure interior mutability is a well established design pattern. I'm not really familiar with the pattern you're describing using Ref/RefMut wrapping, could you show me what you mean?

    Yeah I didn't want to pour a bunch of time into wrangling borrow checker stuff for a small code snippet.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 days ago (1 child)

    Actually, I didn't notice your use of clone() which is even worse.

    Here is what I had in mind. One can put the T: Default bound on the wrappers themselves to simplify, or add potentially expensive transformations for non-Default types.

  • source
  • parent
  • hideshow 2 child comments
  • Yeah what I wrote was just something to get the idea out, about having a list of Allowables.

    I just fully read your code, and I like how you changed the Allowable api to have a deny and allow function instead of it being at the AllowList level. Honestly, I did not know mem::take was a function. I like how you got around cloning too.

    Also, just so you know, you come off pretty rude. Just want to make sure you know that if you're not aware.

  • source
  • parent