[pkolaczk]

1. You can solve these issues with weak references.

2. A lot of stuff that need doubly-linked lists is enclosed in libraries anyways, so you don't need to worry about it.

3. Reference cycles are ugly even in GCed environments and generally should be avoided. They make programs hard to understand and follow.

[Joker_vD]

> They make programs hard to understand and follow.

Really? Using a lookup table to annotate objects externally instead of stuffing annotations inside the objects themselves makes programs harder to understand and follow? No, it's having objects with hundreds of fields that get gradually filled by different places in code too makes programs harder to understand, because it's unclear what data is available where and when. Having children in tree-like structures have pointers to their parents makes programs harder to understand and follow? Again, no: when traversing a tree one can do without to-parent pointer available in the children by stuffing it in the traversal context, but that too makes the program harder to understand.

[pkolaczk]

If you stuff annotations inside objects in order to locate other objects, you're technicality still making references. Whether you use an integer index, string key, pointer or a thing called "reference" in your language doesn't really matter that much - it is just an implementation detail.

What I meant was you should structure the program in a way to avoid circular dependencies, instead of pretending to not having them by using indexes/keys.

> Having children in tree-like structures have pointers to their parents makes programs harder to understand and follow

Yes. It is not a tree anymore. It is a graph, and even not a simple DAG. More state = harder to follow and more ways it can go wrong. For example pointers could not properly match (the parent pointer doesn't point to the correct parent). Circular dependencies also make it impossible to initialize objects without temporarily inconsistent states.

BTW I've seen real memory leaks in GCed (traced) programs because of improper use of such back-references to parent. It is really easy to screw up such structures e.g. when copying, by forgetting to update some of these references and letting them point to the old structure, keeping it in memory.

And what's even worse are circular dependencies between different components in a program. I worked on big codebases where figuring out the proper initialization order was a huge PITA because of reference cycles. And failures to get it right manifested with subtle null pointer exceptions. I'd really love the language forbid them and forced developers to strive for simpler designs.