[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 #14 from anonymous4 <dfj1esp02 at sneakemail.com> ---
(In reply to Marco Leise from comment #13)
> 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.
Implicit conversion for structs without indirection took precedence here. In
practice such struct seldom need elaborate management and you can opt out.
Though the same argument is true for const too.

> It is for example common to enter a critical section that protects some
> shared variables and then cast away shared.
As a general note you should consider what you do when you implement manual
multithreading. It can be also designed in many ways, casting may be not part
of the design.

> The problem we have understanding each other comes from shared not being
> fleshed out.
Your complaints are applicable to const too. That would mean const is not
fleshed out either?

> 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.
Implicit casting violates this reasoning. When data used by multiple threads is
implicitly casted to thread local, how can it work in your understanding? What
will disallow to casually use it? Like for const. If you want shared data to be
different, implicit casting erases that difference without a trace, and the
point is lost, it becomes C type system where anything converts to anything
silently.

--