I like this approach for Rust in general when it comes to graphs. But it suffers from many of the same kinds of issues we get with pointers, e.g. dangling pointers, use after free, and so on. Tradeoffs!
If you want to go one step further, a lot of game development uses a generational index, where the index is both a value and a generation, allowing you to know whether the index you currently have stored references an object that has already been destroyed and replaced by another object. Basically every ECS framework I've ever seen uses this pattern.
I like this approach for Rust in general when it comes to graphs. But it suffers from many of the same kinds of issues we get with pointers, e.g. dangling pointers, use after free, and so on. Tradeoffs!
If you want to go one step further, a lot of game development uses a generational index, where the index is both a value and a generation, allowing you to know whether the index you currently have stored references an object that has already been destroyed and replaced by another object. Basically every ECS framework I've ever seen uses this pattern.
Interesting. Can you provide a good link regarding generational index?
I was originally introduced to the idea by this RustConf 2018 keynote: https://kyren.github.io/2018/09/14/rustconf-talk.html. It's rather dense though.
I did find this random article that outlines just the concept of generational indices pretty concisely: https://lucassardois.medium.com/generational-indices-guide-8e3c5f7fd594
Thanks
That same keynote is linked in the last paragraph! :) The
slotmapcrate is also one option for generational indexes.Ah, you're right! Somehow I missed that, good catch.