On Saturday, 24 January 2015 at 23:28:35 UTC, Jerry Morrison
wrote:
This is the first I've heard that allocating GC memory in a
destructor will crash. That's an unexpected gotcha. I'd expect
to be able to reliably do I/O or throw an exception.
Strategy 1. Fix the GC's limitation. (One fewer pitfall to
baby-sit.)
I expect this to happen sooner rather than later. GC is currently
a very hot topic, with several people working on different
aspects of it (performance, preciseness...).
Strategy 2. Have the compiler inform the programmer. (The
compiler can't catch all bugs but it should do what it can.
Arguably this is a GC bug, not mine.)
Might be worthwhile if we don't manage to remove the GC
limitation before, say, 2.068. But it will also trigger some
false positives. It's unfortunate that currently the class/struct
distinction is tightly coupled with the memory management
strategy.
Strategy 3. Put bold warnings in the reference
<http://dlang.org/class.html#destructors> and all tutorials.
That's useful but insufficient. Programmers will carry
assumptions from other programming languages. Even those who
read the D reference won't all remember that detail when it
matters.
Agreed.
Strategy 4. Accept such crashes. (No good. The D home page
promises safety.)
Strongly agreed. IMNSHO we should try hard to detect errors
already at compile time, even if it means disallowing potentially
harmless things. It's just that in this case, the right thing to
do is to fix the GC (and make writeln @nogc). This btw also
applies to the other problems destructors have, like that the
order of destruction of objects referring to each other is
undefined. The GC should try to zero all references that it knows
are GC managed, and are no longer life, before calling the
destructor.
