@Araq: > B/D does mention that cycles are really rare but can come up.
I'd love to see concrete examples of such cycles to see if the end can be achieved by other means... > the cycles that cause trouble in practice for Swift etc. are those resulting > from closures pointing back to some "upper layer" and afaict these cycles are > prevented. Statically. Yes, that's how the Elm compiler (version 0.19) rejects cyclic data statically. Without mutation or pointers, they can always be detected as the only other way to cause them is through closures. However, **our closures can contain `var` 's/`ref`'s/`ptr`'s whose contents can be mutated to point back to "some upper layer" after creation**, and I don't know that those can be detected. I suppose the same can be done in Swift/etc. and isn't to worry about as pointer manipulations are "unsafe behaviour"? > Having said that, I'm still musing and tinkering whether some variation of > these ideas wouldn't work out better for Nim, as **adding owned to everything > is a pretty disruptive change**. Now that is interesting, as **I understood you were completely committed to seeing how `owned` works out for `newruntime`**. Let me just throw an idea out for your consideration; it may be completely wrong, but then I have been before :-) , as follows: 1. Suppose that the **" everything can be `owned`" principle** that I raised in issue #12021 which the compiler already supports but you said shouldn't as "the compiler isn't ready for it yet" were to be accepted as the way the newruntime would work. 2. Further, suppose that the rule of **" everything is created as owned"** were enforced by the compiler, which "everything" **would include all primitives and literals** as well as all the other things you already consider as being created owned. 3. Now, we wouldn't have to worry about adding **`owned`** everywhere as that **would be implicit**. 4. The compiler already detects when we are trying to **copy an `owned`** and errors out, so why not have it **inject an `unown`** instead and proceed rather than forcing us to manually inject it. 5. If this were done, the main **problem would be that the programmer couldn 't easily tell by code inspection whether a given binding is `owned` or not** as it may be difficult to keep track of whether a given use is "last read of" or not, **but the compiler always knows through its data flow analysis** as the whole B/D implementation for owned depends on it. 6. Thus, if the programmer tries to do something they shouldn't, **the compiler can still give them an appropriate error message** , or, if not, the **" dangling" detection will catch it at run time** if turned on (for debugging or otherwise). The above is starting to stink of Rust's ideas of ownership, but at least it doesn't have a onerous syntax of lifetimes and reference notations to deal with (I hope; it's worse than the newruntime as already proposed if it does). The one problem I can immediately see is how to handle the cases (reasonably rare, except for multi-threading) when **multiple ownership needs to be handled** , and for that I can't see any other way than a deepCopy or a reference counted reference, which are Rust's two solutions to the same problem (Clone traits that can include use of RC/ARC). I don't think we ever want to see system.deepCopy come back again, but maybe we just do something like override system.shallowCopy to actually do a deep copy for these cases, as perhaps shallow Copy isn't usually used, or maybe we have a new system.clone that normally does a shallow copy but can be overridden to do either this deep copy or a reference counted wrapper copy chosen by the programmer as suitable for the particular need? It seems to me that **such a system would offer the advantages of B /D** of optional better performance than reference counting or Garbage Collection (especially when dangling checks can be turned off) and at least some detection of cyclic data if not the actual handling of it while not adding too much extra syntax burden and **while also supporting an easy workaround when single ownership isn 't appropriate.** But, OTOH, **I may be completely wrong** and such as system isn't possible in Nim... :-)
