• Vlad Levenfeld (12/12) Jul 19 2014 I have a Resource struct that is supposed to free some memory
• Jonathan M Davis (13/19) Jul 20 2014 What you will probably need to do is to not try and use the same
• Vlad Levenfeld (16/24) Jul 20 2014 Unfortunately this option would require an unrealistic lot of

"Vlad Levenfeld" <vlevenfeld gmail.com> writes:

I have a Resource struct that is supposed to free some memory 
when it gets destroyed. Unfortunately, I can't define a 
destructor. If I do, the compiler complains that it can't destroy 
the shared versions. If I define a shared destructor, the 
compiler complains that it can't disambiguate between ~this() and 
shared ~this().

Is there a way around this or a better way to accomplish what I'm 
trying to do? I just want a lightweight handle to a 
manually-allocated dynamic array that I can append to and stuff, 
and frees itself on destruction (so I can keep them in various 
containers and know that freeing will automatically happen when I 
remove it).

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Sunday, 20 July 2014 at 02:57:44 UTC, Vlad Levenfeld wrote:
 I have a Resource struct that is supposed to free some memory 
 when it gets destroyed. Unfortunately, I can't define a 
 destructor. If I do, the compiler complains that it can't 
 destroy the shared versions. If I define a shared destructor, 
 the compiler complains that it can't disambiguate between 
 ~this() and shared ~this().

What you will probably need to do is to not try and use the same 
type as both shared and non-shared if it has a destructor. If 
it's going to be used as shared, then give it a shared destructor 
and make all of its other relevant functions shared. If it's 
going to be used as thread-local, then don't make any of it 
shared.

I would however suggest that you report this as a bug, since it 
really should be able to distinguish between shared and unshared 
destructors.

shared is a great concept, but we are going to need a few 
adjustments to its design in order to make it properly, fully 
useable.

"Vlad Levenfeld" <vlevenfeld gmail.com> writes:

On Sunday, 20 July 2014 at 08:29:55 UTC, Jonathan M Davis wrote:
 What you will probably need to do is to not try and use the 
 same type as both shared and non-shared if it has a destructor.

Unfortunately this option would require an unrealistic lot of 
refactoring for me. I'm basically using this thing as a drop-in 
replacement for arrays, so they go everywhere. I use array-based 
swap buffers to transfer data between threads. I have to declare 
the buffers shared, which makes the arrays shared.
This problem only emerged when I decided I wanted them to free on 
destruction, so it looks like I'll be sticking with manual free 
for awhile longer.

 I would however suggest that you report this as a bug, since it 
 really should be able to distinguish between shared and 
 unshared destructors.

Would it be considered a duplicate of 
https://issues.dlang.org/show_bug.cgi?id=12004 ? At least, all of 
my use cases agree with the bug filer's argument against having 
any shared dtors.

 shared is a great concept, but we are going to need a few 
 adjustments to its design in order to make it properly, fully 
 useable.

Agreed. It's given me a few headaches in the past, but I do like 
the idea of a transitive qualifier that helps me identify 
potentially racy data.