undefined | Better HN

0 pointsnu11ptr4y ago0 comments

`Rc` and `Arc` have weak references which have worked just fine for me to break cycles in a graph. Not saying my use case is the most complex, but I haven't noticed this as a problem yet. YMMV

0 comments

4 comments · 2 top-level

jerf4y ago· 1 in thread

If your data is "mostly a tree but has the occasional back reference I can easily identify as a back reference", that works great and I've used it in other languages.

But in the limit, as your data becomes maximally "graphy" and there isn't much you can do about it, this ceases to be a viable option. You have to be able to carve a "canonical tree" out of your graph for this to work and that's not always possible. (Practically so, I mean. Mathematically you can always define a tree, by simple fiat if nothing else, but that doesn't help if the only available definitions are not themselves practical.)

nu11ptrOP4y ago

Fair point - so far I've been lucky enough to avoid such use cases

zozbot2344y ago· 1 in thread

But the whole point of weak references is that they don't get shared ownership (i.e. extend the lifetime) of their referenced values. That's not doing GC. They're fine when there's always some other (strong) reference that will ensure whatever lifetime is needed, but that's not the general case that GC is intended for.

nu11ptrOP4y ago

Weak pointers don't create a strong reference, correct, and that is exactly what is needed to break a cycle. Since it is a cycle, there is some other "owning" strong reference out there. Every use case I've seen generally has an obvious strong and weak reference (usually parent vs child). I'm sure there are trickier corner cases, but that is the typical IMO.

For everything else, Rust has no need for a tracing GC, as it has "compile time" GC via static lifetime analysis which is much better IMO already and often avoid heap allocation all together.

j / k navigate · click thread line to collapse