[Issue 8295] Struct member destructor can not be called from shared struct instance

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=8295

--- Comment #13 from Marco Leise <Marco.Leise at gmx.de> ---
(In reply to anonymous4 from comment #12)
> (In reply to Marco Leise from comment #10)
> > You can tell where I'm going: Copy a shared reference counting struct and it
> > is no longer shared except for the data it references.
> If you can solve it for const, the same solution can work for shared, but it
> doesn't deny overloading on qualifiers.
> [...]
> > Value types can always be copied stripping their top-level qualifiers!
> That's fine, but this problem isn't solved yet for transitive qualifiers.

No it is not fine, because if we agree that top level qualifiers are free to
change after a copy, and it seems sensible to say that the shared status of a
copy is opt-in, then how would Dlang know that the struct copy should be
destructed with the shared (or const to keep the analogy) destructor?
Against the spec that put shared and const on equal ground, you would have to
force all copies to be shared, too. Personally I feel the spec is right: The
moment you copy something, it is thread-local and mutable. It may contain
pointers to data that is const or shared, but that is on a different level.
That's why I said there can only be a SharedRefCounter and that
shared(RefCounter) doesn't work.

It is for example common to enter a critical section that protects some shared
variables and then cast away shared. You could then blit a previously shared
reference counting pointer variable to a local copy and work with that. Upon
destruction it wouldn't know that it should apply shared semantics to the
reference count.

The problem we have understanding each other comes from shared not being
fleshed out. For me it is a tag that you apply temporarily while data is
_currently_ in use by multiple threads, just so you don't casually read from or
write to it and expect it to work. For you it has semantic meaning as a type
constructor, sticks with copies and eventually decides which destructor
overload to use. And since I was in the same camp two years ago I may change my
mind again, but ultimately a decision has to be made here.

--