> I'm glad to see you take a combination of the Rust and my ideas and run with > it (although I haven't seen your RFC as suggested by @Araq yet).
Well, I need to specify my proposals further. A proposal has to be complete. Otherwise, it is pointless. There is a difference with a scientific paper: Within a scientific paper, I tend to describe possibilities and possible solutions for some use cases. I could claim that something is "type-safe" , but then, I have to prove it. > As well, B/D doesn't seem to apply in all cases where one must have multiple > owners such as for the sub-nodes in a binary tree, and therefore, in their own compiler implementation (Gel), B/D blocked RC-based deallocation (hehe..) . This can simply be achieved with a root provided with static lifetime. But then and by the way, RC can be skipped, making the compiler faster. > Yes, this is a list which isn't really very useful, but the same principles > apply if it were a more useful structure such as a binary tree (with cycles). Nice trap. With a specific return type, capability `iso` (pony-style), the code would not compile. The "result"-ptr would point to something that is already referenced , and therefore breaking the `iso` \- cap. Regarding ownership in a tree: As tree has dedicated ownership - always. There are branches that contain dedicated "owners" to other branches and the leaves. Assuming that branches and leaves have the same `Node` type, the "owners" in the leaves are set to zero. If there are other pointers/references to branches or leaves existing in the memory, these aren't "owners". Instead, the nodes are shared with (at least one) "aliasing" pointers. The relevant aliasing ptr is the ptr with the longest lifetime. It is crucial to know that relevant ptr.
