The idea is nice, it would help newcomers a lot.
But please also think about the people that are using D _without_ a
garbage collector. I wouldn't want the compiler to complain about
something that isn't even true with my modified version of druntime.
Kind Regards
Benjamin Thaut
I've suggested to add a little piece of static analysis inside the D
compiler, able to catch all cases of a specific kind of bugs:
http://d.puremagic.com/issues/show_bug.cgi?id=8293
A short thread in D.learn about a
core.exception.InvalidMemoryOperationError:
http://forum.dlang.org/thread/[email protected]
Caused by this code:
class X {
string[string] s;
this() {
s["s"] = "S";
}
~this() {
s.remove("s");
}
}
void main() {
X x = new X();
}
Jonathan M Davis:
you should never do anything in a class' destructor/finalizer which
could ever trigger the GC in any way.
In past I have seen other similar bugs discussed in D.learn.
I think a small amount of static analysis code added to the D front-end
can statically avoid every bug of this kind. This code has to look
inside ~this(){} and work recursively (like purity and nothrow
enforcement do), searching for functions that perform GC activity.
(This is a bit different from the enforcement of the @noheap annotation
I have suggested in Issue 5219 because it's OK to manage C-heap memory
inside the destructor, while @noheap looks for C-heap activity too
(malloc/realloc/calloc)).
Bye,
bearophile
