An idea to avoid a narrow class of bugs

[Benjamin Thaut]

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/js649p$1707$1@digitalmars.com
>
> 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