this post was submitted on 23 Jul 2026
7 points (100.0% liked)

Rust

8149 readers
13 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 3 years ago
MODERATORS
 

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.

top 5 comments
sorted by: hot top controversial new old
[–] ExperimentalGuy@programming.dev 3 points 5 hours ago* (last edited 5 hours ago)

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.

[–] TehPers@beehaw.org 1 points 4 hours ago

Does your function need to accept &mut self? If you can redesign that function just to take the slice of game objects (fn update(objs: &mut [T])) then you don't need to worry about the aliasing at all. You can pass an index as well if you want to operate on them one at a time.

This is actually closer to the strategy you'd see with ECS. You'd operate not on individual objects, but on all relevant objects at once.

[–] chrash0@lemmy.world 6 points 8 hours ago* (last edited 8 hours ago) (1 children)

classic. this has been a problem since the language was new.

the problem is that Rust is designed to not have this as a use case, or rather has machinery to make this marginally safer (mutexes etc) or make it unstable (panic) or just as unsafe as C (unsafe). if this is a pattern you want to maintain, Rust is going to throw friction at you by design, because tbh this pattern is the source of a ton of bugs.

it’s conceptually more complicated, but game engine devs have been moving to some form of Entity Component System[1] architecture, because it gives you a way to access memory that is both cache efficient and safe.

all that said i’m not a game dev. i think Bevy[2] was the blessed solution for a while?

1: https://en.wikipedia.org/wiki/Entity_component_system?wprov=sfti1 2: https://bevy.org/

[–] ExperimentalGuy@programming.dev 1 points 5 hours ago

I don't think you need a mutex for this situation.

[–] BB_C@programming.dev 2 points 8 hours ago

Can you clarify/expand on what you mean.
Are the other objects of the same type (so are indeed Self)? Are they in the same Vec or a different Vec or from different Vecs?
Are all the T's in your post the same?
...etc