Since shared hasn't change much in the last years, I assume it
is somewhat accepted in its current state. My understanding is
that if something cannot be attributed to a single thread, it
is "shared". So far so good.
Now I wrote an object pool struct with two properties: it can
be used by multiple threads during its lifetime and this(this)
is disabled. Logically the struct is both created and
destroyed while only the creator thread (which holds the data)
has access to it and there is no two ways about it. An
object can only be destroyed when it is no longer shared.

Yet the D compiler asks for a shared ~this(). This sounds as if it asks me to commit a logical error. So the question is, how do I define a shared struct without a shared ~this() which would be broken by definition?

-- 
Marco

On Sunday, 26 January 2014 at 17:15:10 UTC, Marco Leise wrote:
> Since shared hasn't change much in the last years, I assume it
> is somewhat accepted in its current state. My understanding is
> that if something cannot be attributed to a single thread, it
> is "shared". So far so good.
> Now I wrote an object pool struct with two properties: it can
> be used by multiple threads during its lifetime and this(this)
> is disabled. Logically the struct is both created and
> destroyed while only the creator thread (which holds the data)
> has access to it and there is no two ways about it. An
> object can only be destroyed when it is no longer shared.
>
> Yet the D compiler asks for a shared ~this(). This sounds as
> if it asks me to commit a logical error. So the question is,
> how do I define a shared struct without a shared ~this() which
> would be broken by definition?

I ran into this issue some time ago too.
https://d.puremagic.com/issues/show_bug.cgi?id=8295
Walter stated in a discussion on the newsgroup that this is by
design. It basically came down to, that shared structs should not
be destroyed ...
Although I really don't agree with this, it should be fixed. In
my opinion it should not be neccessary to have a shared
destructor, because as soon as it is destroyed, it is no longer
shared. So no special shared destructor should be neccessary.

Am Sun, 26 Jan 2014 21:36:58 +0000
schrieb "Benjamin Thaut" <code@benjamin-thaut.de>:

> On Sunday, 26 January 2014 at 17:15:10 UTC, Marco Leise wrote:
> > Since shared hasn't change much in the last years, I assume it
> > is somewhat accepted in its current state. My understanding is
> > that if something cannot be attributed to a single thread, it
> > is "shared". So far so good.
> > Now I wrote an object pool struct with two properties: it can
> > be used by multiple threads during its lifetime and this(this)
> > is disabled. Logically the struct is both created and
> > destroyed while only the creator thread (which holds the data)
> > has access to it and there is no two ways about it. An
> > object can only be destroyed when it is no longer shared.
> >
> > Yet the D compiler asks for a shared ~this(). This sounds as if it asks me to commit a logical error. So the question is, how do I define a shared struct without a shared ~this() which would be broken by definition?
> 
> I ran into this issue some time ago too.
> https://d.puremagic.com/issues/show_bug.cgi?id=8295
> Walter stated in a discussion on the newsgroup that this is by
> design. It basically came down to, that shared structs should not
> be destroyed ...
> Although I really don't agree with this, it should be fixed. In
> my opinion it should not be neccessary to have a shared
> destructor, because as soon as it is destroyed, it is no longer
> shared. So no special shared destructor should be neccessary.

*nod*
But you must have misunderstood Walter. Keeping shared structs
alive forever certainly doesn't work. :p

-- 
Marco