forcing "@nogc" on class destructors

[Jerry Morrison via Digitalmars-d]

On Tuesday, 27 January 2015 at 22:46:30 UTC, Ola Fosheim Grøstad 
wrote:
> On Saturday, 24 January 2015 at 23:28:35 UTC, Jerry Morrison 
> wrote:
>> On Saturday, 24 January 2015 at 15:04:47 UTC, Ola Fosheim 
>> Grøstad wrote:
>>> If the classes are written for RAII then the destructors have 
>>> to be called in reverse order of the constructors. IIRC D 
>>> does not guarantee this when you use the GC.
>>>
>>> So to do it right there is a lot of GC overhead.
>>
>> Yes, but the usability question is what do programmers expect? 
>> How much do they assume before turning to the docs?
>
> Unfortunately, I think D is now entrenched in Java/C#ish 
> expectations. Which is no good, since the main advantage D can 
> have over those languages is to restrict the language semantics 
> to a level where D has an inherent performance (timeliness) 
> advantage.
>
> My expectations from a GC in a system level programming 
> language would be to give max priority to fast collection at 
> the expense of features (lean and mean).
>
>> It's a big stretch to expect LIFO behavior from garbage 
>> collection. It's not a stretch to expect logging to work.
>
> What does logging in a destructor tell you? The destructor 
> might not execute until the program terminates.

Logging might help with debugging, say, to log accumulated data 
before the object disappears. Perhaps it's not a great example, 
but since logging doesn't do anything dubious like forging a 
strong link to the object, it would seem safe at first 
expectation.

Because of this unknown delay before GC collection, also because 
GC can collect a cycle of objects, we know it can't promise LIFO 
order.

> You might not expect LIFO from the GC, but can you trust 
> library authors to ensure that it does assume LIFO when manual 
> memory management becomes commonplace?

Sorry, I don't understand the question. I expect LIFO for freeing 
structs on the stack.

> D needs to define what it means by "safe" and "convenient". It 
> is currently very much up in there air when it applies and when 
> it does not.

Yes.

The forum discussion 
http://forum.dlang.org/thread/gvaacvczsrybguddoogq@forum.dlang.org?page=1 
deals with an InvalidMemoryOperationError. Vladimir Panteleev 
created a wiki page 
http://wiki.dlang.org/InvalidMemoryOperationError on how to debug 
such cases, starting with building a patched Druntime. Very 
helpful, but not easy.

==> It would be a big step forwards if the runtime printed a 
clear error message like: "Attempt to allocate GC memory within 
the destructor for class Foo."