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.
