I've been reading all the topics with those "radical" ideas about
the GC and dtors and, honestly, i'd rather call them "insane".
After all the reading and thinking, i came to conclusion, that
what Andrey suggests is to call dtors only on stack-allocated
structs. That also implies, that one can't put those in
containers and gc-allocated objects.
Since all of them: containers, structs, classes -- are all
first-class objects they must be all nicely combined in code,
without any unintuitive stuff.
I mean, really, let us look at c++ strings. There are const
char*, std::sting, QString, Poco::String, icu::UnicodeString, and
every big project uses it's own strings implementation that can't
be used together in a sane way. That is what great in D: you just
threw the idea of library-implemented strings away and made it
not only "standard", but special and that what makes it intuitive
and simple (unless you interact with c++). Never seen any
non-standart strings for D.
The point is, that every library and every coder add to the
project incompatible and difficult to use together stuff, so
every programmer already has to think of all the problems with
other's people code, and you just can't add same shit to the
language. All elements must nicely interact together and
otherwise it's a total disaster.
Back to the dtors: i understand, that all the stuff you propose
could make GC faster, simpler, and cooler, but it sounds insane
to anyone, who uses the language, not develops it, that if you
create struct object, dror will be called, but if you place the
copy in a container, it wont. It's just unanderstandable from
user's point of view.
Now, for the solution.
First, we can just fix this shit with arrays of structs and
that's it. That still lives us with false pointers problem: not
everything gets collected. That's no good. So, i propose to think
of actually separating gc-memory management (via GC) and other
resources management: via some new (or maybe old) mechanism.
Let me start with listing of existing solutions:
1) C.
That is the simplest way: fully-manual resource management.
It's obvious, we can't do that in D, because it's supposed to be
simpler for coding, than C.
2) Go.
Actually, this one is not that different: it uses GC for memory
only, and manual management for all the rest (with help of defer
operator). We can't do it either, for the same reasons.
3) C++.
This one is semi-automatic (talking about user code, not some
allocator libraries): you choose the scheme (refcounting, unique
reference) and then it'll do the rest.
4) Rust.
I'm not a pro here, but as i understand, it uses C++ way, and
adds gc-collected pointers, but not sure, so help me here.
5) Python.
GC-only, except one clever case: with statement calls close()
method.
Please, if there are any pros in other platforms, add your
knowledge to this list, i would very much love to learn (same, if
a made any mistakes).
Now, for D: obviously D has GC-managed heap. First, we should,
like in Go, leave only managing gc-memory to the GC -- this is
just rephrasing Andreys proposal.
The simplest way o manage all other resources would be manual,
Go-way:
A a = A();
scope(exit)
a.~A();
But it's to annoying, to that all the time, so we really want
dtors to save us lost of typing and debugging, but they can't be
called all the time, because we can put stuff in GC-collected
objects.
What i propose, is to include new concept in D: scoped objects.
Any object (no matter is it a class or struct instance) can be
either scoped or not.
Dtors for scoped objects are called when out of scope, dtors for
non-scoped objects are not called at all.
It is actually as simple as rewrite code
A a = A();
as
A a = A();
scope(exit)
a.~A();
For all a's, which are scoped objects.
For me, it is both a simple concept and good rationalization for
difficult dror-gets-called-or-not rules.
That leaves only to determine, what objects are scoped. Well,
that is obviously stack-allocated structs, gc-allocated scope
classes and gc-allocated structs in scope classes.
But that is just my idea. This post has so many words, because
it's very important, that D devs make good decision on that deep
problem, and the key to such decision is information and
discussion.
UPD:
Also, about arrays and slices: if we could easily pass them
around as cost ref-s, just like in C++, then we could make them
value-types and they wouldn't require any ref counting. I would
suggest, make all "in" function arguments const refs.
