Am 01.02.2014 05:33, schrieb Frank Bauer:
Yes, that is what Rust calls an "owning pointer". While we are at it, we
might as well dream of "non-owning" or "borrowed" pointers, a.k.a.
references in Rust. They don't have an effect on memory-deallocation
when they go out of scope, but they prevent the owning pointer they
"borrow" from (i.e. are assigned from) from being reassigned to a
different object as long as there are borrowing references in scope.
There is more to owning and borrowed pointers, but I think that is the
essence.
@Andrei (who I believe is the go-to (!) guy for all things memeory
allocation related right now):
IIRC you mentioned that it was convenient to have the GC around for
implementing the D language features. Would it just be a minor
inconvenience to drop that dependency in the generated compiler output
and replace it with new/delete or something equivalent to owning
pointers, say over the next one or two years? Or would it be a major
roadblock that would require too much redesign work? Maybe you could
test the concept of owning and borrowed pointers internally for some
compiler components before actually bringing them "to the surface" for
us to play with, if it turns out useful. But only of course, if we could
leave the rest of D as good as it is today.
I would really like to see the GC-free requesting crowd be taken a lttle
more seriously. Without asking them to forego D features or do manual
C++-style memory management. Javas and .NETs garbage collectors had
enough time to mature and are still unsatisfactory for many applications.
Just to nitpick, reference counting is also GC from CS point of view. :)
