forcing "@nogc" on class destructors

[via Digitalmars-d]

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.