@MrZoraman I think interop between `owned ref` and a GC is solvable: * Stdlib has `owned` annotations and can be used without the GC. * If a GC is enabled the stdlib also uses it but the compiler's job is to still ensure that non-memory destructors are called deterministically. Then you still need to get ownership right for your sockets etc. This means that `owned ref T` is not ignored when `T` has a custom destructor.
Whether that works in practice remains to be seen. We can also think about a distinct `GcRef[T]` type. But at this point we don't know how well `owned ref T` will work out and we should stop thinking about adding even more complexity on top of it just to please the "I don't want to think about memory management" argument, sorry. 1. You have to think about memory management even when you have a GC. 2. You have to think about resource management as the GC doesn't solve it. 3. The proposal is different enough that lessons from Rust might not be applicable. 4. It's not about a 5-10% performance difference, the Nim compiler spends 25% of its runtime in the GC and that's with the mark&sweep GC, refcounting is slower! And with the existing GCs and `.gcsafe` system we're hitting an optimization barrier. Going from `ref T` to `ptr T` everywhere in order to avoid the GC seems to be unjustifiable. Now the compiler itself might be doomed and live with the GC forever -- it's a large codebase that creates cyclic data structures everywhere but we can learn its lessons for other Nim projects.
