Is this a bug?

[Alex via Digitalmars-d-learn]

On Sunday, 4 May 2014 at 10:28:30 UTC, Mike Parker wrote:
> On 5/4/2014 6:42 PM, Alex wrote:
>> Hello,
>>
>> I am trying to use the std.log module that is here:
>>
>> https://github.com/linkrope/log.d
>>
>> And I encountered a segmentation fault using dmd 2.065 on a 
>> Linux 64
>> platform. The reduced test case is this:
>>
>> //============================================================================
>>
>> import std.stdio;
>> import std.log;
>>
>> private class CHello {
>>
>>     ~this() {
>>         info("info - destructor"); //info, warning, error 
>> segfault;
>> however, writefln works
>>     }
>> }
>>
>> void main(string[] args) { CHello chello = new CHello(); }
>> //============================================================================
>>
>>
>> Is this a bug?
>
> No, it is not a bug. It's a hazard of destructors in D.
>
> Because of the GC, there are certain things you cannot rely on 
> when it comes to destruction. One is that there is no guarantee 
> that the destructor will ever be called during the lifetime of 
> the app. The second, and likely the problem you're seeing, is 
> that you cannot rely on the order of destruction.
>
> If you look at the source for std.log, you'll see that info() 
> ultimately (via some templating) maps to an instance of 
> LogFilter, which is a class allocated on the GC heap in a 
> module constructor. When the app exits, one of the last things 
> DRuntime does is to terminate the GC (see rt_term in dmain2.d 
> in the DRuntime source). The current implementation of the GC 
> will run destructors on any objects still resident on the heap 
> during termination. There is no way to guarantee the order in 
> which those destructors will be run.
>
> Most likely, what you're seeing is that the LogFilter instance 
> referenced by the info template is being destroyed before the 
> destructor on CHello is run. Therefore, you're referencing an 
> invalid memory location.
>
> The short of it is that you should never touch anything on that 
> lives on the GC heap from inside a destructor -- there's no 
> guarantee that it will still be alive when your destructor is 
> run.

Thank you, but I find it to be quite awkward. Why the compiler 
does not complain or, at least, give a more meaningful runtime 
error message? Is there any official std.log that is 
destructor-safe?