On Saturday, 29 August 2015 at 13:58:07 UTC, ponce wrote:
Example 1:
You forget to release Resource A. The GC happen to call A
destructor that releases it. But GC destructors are not
guaranteed to happen.
See http://dlang.org/class.html ("The garbage collector is not
guaranteed to run the destructor for all unreferenced objects").
This, ok, it is the common GC flaw that it shouldn't memleak but
might. To me it isn't either an "accidentally correct design" nor
an "avoided leak" but ok. If something _has_ to be freed then it
should be done explicitely either way hence crashing the GC for
that particular ressource, I follow you here.
Example 2:
Resource A depends on Resource B. You forget to release either.
The GC happens to call A and B destructors in the right order,
by chance. A new D release changes this order later.
Here comes the accidentally correct design. Ok, I'm with you on
that one.
I think however that this should really be limited on ressources
that _must_ be freed in time. It shouldn't become a standard way
to deal with the GC.
