Nim has been - and continues to be - attractive because it is a PL with
"batteries included". The GC makes Nim "complete" \- well, not 100% complete,
but _almost_ complete.
The majority of imperative PLs do not come along with automatic memory
management. This makes them somewhat _incomplete_. Java did not get success
despite its garbage collector. Instead, the GC was an integral part of its
success from the very beginning.
The Bacon/Dingle approach is "nothing new under the sun". If these simple
concepts had worked, we had already seen them: At the time, when PASCAL and
SCHEME were introduced, in the (early) 70ies. These times are long gone and
nothing happened. Why? It was tried, but it didn't work and it doesn't work.
So, your `owned ptr` is not exciting. Forget the `owned ptr` and introduce the
`gcref` instead: For pointers that need tracking with a GC or RC. It is a
semantical question: the `owned ptr` can be an `owned ptr` in many different
ways. If we really want an `owned ptr`, we just need a couple of them!
> There is no "arbitrary rejecting of RC" going on here, the reasoning behind
> it is very clear: RC is a form of GC, just more incomplete than a tracing GC.
> B/D however, is different: It turns the imperative manual memory management
> with its dealloc calls into a declarative style. The hope is that it
> encourages a design that prevents logical memory leaks (leaks that full
> tracing GCs don't prevent either!) by construction.
B/D follows a strict and simple rule: The lifetime on the stack determines the
lifetime on the heap. Therefore, RC (or another GC) can be left out completely.
B/D runs into difficulties, if there are "static" containers available
("static" means persistent lifetime) and if structures can be referenced via
these containers, e.g. a List[T] or Listbox[T] or with another fancy name. B/D
breaks down if a directed acyclic graph needs to be implemented. A DAG is a
"logical error" in the B/D system conceptually. How nice is that.
Did we get "something new under the sun" in the recent years? Well, the Pony
approach. The Pony-people did not intend to redefine automatic memory
management. But "capabilities " and "viewpoints", slightly modified, could be
used for that. The tension between capabilities of fields and pointer-members
in the fields is clearly addressed in Pony. It can be analyzed at compile time.
Rust tries to do that too. But Rust is not expressive enough. And B/D simply
ignores it.
