5 ms·
I think the disconnect for me is that circular references just aren't "irregular", they are the natural expression for doubly linked lists, trees with reference
by esrauch 8y ago
I think the disconnect for me is that circular references just aren't "irregular", they are the natural expression for doubly linked lists, trees with references to parents, etc: these usage patterns are the primary cause of memory issues that I come across in C++.
In other words, static safety in the face of circular references is what would provide me a major clear advantage for better-than-C++, and unfortunately that doesn't seem to be something that is even seen as an opportunity for Rust given all of the rhetoric about that being an abnormal pattern and index-into-array being safe enough under that world.
- littlestymaar 8y ago> In other words, static safety in the face of circular references is what would provide me a major clear advantage for better-than-C++, and unfortunately that doesn't seem to be something that is even seen as an opportunity for Rust. Having a compiler able to solve the halting problem would also be “a major clear advantage for better-than-C++”, but too bad it's impossible … Arbitrary circular graphs can't be statically managed, that's it. Your need a runtime support, and it will either be a garbage collector, or some kind of constructions with array an indices.
- AstralStorm 8y agoCircular graphs are perfectly possible to detect and manage compile time. It just takes a massively not complex borrow checker to run full dependency analysis to find where and if the cycle is broken or the whole thing released. Checking for graph cycle is elementary CS - planning the entry/exit nodes is not. It is similar to link time optimization to implement.
- staticassertion 8y ago> Checking for graph cycle is elementary CS Yeah, but that's for built graphs, not graphs that will be built at runtime? Seems really, really different.