I need a robust "isCalledByGC" function to leak intentionally when a destructor is called as a result of the GC.

It is a way to enforce deterministic destruction without ever relying on accidental correctness.


class A
{
    ~this()
    {
        if(iscalledByGC())
        {
            [leak and write an error to stderr]
        }
        else
        {
            [normal release of resources]
        }
    }
}


Prior solution: http://forum.dlang.org/post/li2oj4$1avo$1@digitalmars.com but that involves modifying the runtime.

Let me suggest a completely different option: make a destructor that works while the GC is running by managing the resources manually in both construction and destruction. Remember, it isn't *all* reference types that are problematic to access, it is just GC managed references. So anything from a C function is cool.

Otherwise, accessing the runtime variable seems ok to me like the link said, hacky sure, but it'd work.... nothing else comes to mind, other than using a separate dispose() method when you delete it manually and leave the dtor for only the GC.

On Tuesday, 12 May 2015 at 12:31:35 UTC, Adam D. Ruppe wrote:
> Let me suggest a completely different option: make a destructor that works while the GC is running by managing the resources manually in both construction and destruction.

I see, but not all ressources can be disposed by any thread. I'd prefer to make it an error. Also, relying on GC destructors can make a program work by mistake.

> isn't *all* reference types that are problematic to access, it is just GC managed references. So anything from a C function is cool.
>
> Otherwise, accessing the runtime variable seems ok to me like the link said, hacky sure, but it'd work.... nothing else comes to mind, other than using a separate dispose() method when you delete it manually and leave the dtor for only the GC.

I already have such a dispose() function.
The problem is that to support Unique! and scoped! and friends, the destructor must call dispose(). Thus my need for a way to separate the GC-induced destructors within dispose() or ~this (same problem).

On Tuesday, 12 May 2015 at 12:53:59 UTC, ponce wrote:
> I already have such a dispose() function.
> The problem is that to support Unique! and scoped! and friends, the destructor must call dispose(). Thus my need for a way to separate the GC-induced destructors within dispose() or ~this (same problem).

Maybe it's simpler to copy-paste Unique and scoped and modify them to handle disposable objects?

On Wednesday, 13 May 2015 at 11:24:10 UTC, Kagamin wrote:
> On Tuesday, 12 May 2015 at 12:53:59 UTC, ponce wrote:
>> I already have such a dispose() function.
>> The problem is that to support Unique! and scoped! and friends, the destructor must call dispose(). Thus my need for a way to separate the GC-induced destructors within dispose() or ~this (same problem).
>
> Maybe it's simpler to copy-paste Unique and scoped and modify them to handle disposable objects?

But then we would need a standardized name (some use "close", some use "dispose", some use "release")

The closest thing we have to a standardized function name is the destructor.

On Thursday, 14 May 2015 at 17:25:55 UTC, ponce wrote:
> But then we would need a standardized name (some use "close", some use "dispose", some use "release")

In .net the standardized name is "dispose" and IDisposable interface having the method: https://msdn.microsoft.com/en-us/library/System.IDisposable.aspx it also suggests possible operations "free" and "reset". "close" makes sense for files, but files are not the only type of disposable resource.

Another idiom from .net is Dispose(bool) method, called with argument true from Dispose and with argument false from finalizer. https://msdn.microsoft.com/en-us/library/d9yzd5cx.aspx