this post was submitted on 25 Oct 2023
13 points (93.3% liked)
Rust
6133 readers
31 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You can always use something like generational indices. They pop up a lot in ECS systems. A suitable container with an opaque index type prevents creation of invalid references, lets you check reference validity at runtime, and generational indices prevent reuse. The compiler can’t help with lifetime tracking, but that’s a problem with any shared reference type pointing to a resource with a lifetime that can only be known at runtime, eg. Arc.
As far as I understand that approach, it lets you detect dangling references but not prevent them, and it does nothing to detect when a node becomes unreachable. It also imposes a burden on the user to check every reference at runtime before it can be safely followed.
I think I'd much rather use
Rc
with strategic use of weak pointers to prevent cycles. That way at least some of your references can be trusted without verifying them on each use, and resources are freed when they become unreachable.If you need to represent a fully general graph structure, you're pretty much obligated to implement some kind of garage collection on it, so any solution you come up with will be pretty hairy. Fortunately I've never once in my career needed a fully general graph. If you think you need one, it's a good sign that you're in the process of building an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. At that point you're much better off embedding a real implementation of a garage collected language in your system.
I also feel I should point out that the need for the ugly wrapper enum in the article is a side-effect of using an array to store everything. If you use proper references or pointers, you can use
dyn
to automatically support every possible implementation of a trait, not just the ones listed in an enum. You might still want to use the array/enum approach for other reasons, like memory locality, butdyn
references provide a degree of freedom that can be very useful sometimes.If you don’t have a perf requirement like “all these things need to be in contiguous memory” then you probably don’t need a generational index anyway… it is effectively a weak reference, after all. ECS stores are optimised for repeatedly iterating over all the things, and games might have complex notions of “reachability”, but most things aren’t like that. There does seem to be a lot of “I don’t like using Rc RefCell” in object arena design that isn’t always justifiable, though nested generics don’t make for the most readable code in the world.
I think we're more or less in agreement. I lean more towards leveraging language primitives when possible to get the most support from a compiler, but I'll happily acknowledge that there are no one-size-fits-all designs.