Something needs to happen with shared, and soon.

[Benjamin Thaut]

Am 15.11.2012 12:48, schrieb Jonathan M Davis:
>
> Yeah. If the reference passed across were shared, then the runtime should see
> it as having multiple references, and if it's _not_ shared, that means that
> you cast shared away (unsafe, since it's a cast) and passed it across threads
> without making sure that it was the only reference on the original thread. In
> that case, you shot yourself in the foot by using an @system construct
> (casting) and not getting it right. I don't see why the runtime would have to
> worry about that.
>
> Unless the problem is that the object is a value type, so when it goes away on
> the first thread, it _has_ to be destroyed? If that's the case, then it's a
> pointer that was passed across rather than a reference, and then you've
> effectively done the same thing as returning a pointer to a local variable,
> which is @system and again only happens if you're getting @system wrong, which
> the compiler generally doesn't protect you from beyond giving you an error in
> the few cases where it can determine for certain that what you're doing is
> wrong (which is a fairly limited portion of the time).
>
> So, as far as I can see - unless I'm just totally missing something here -
> either you're dealing with shared objects on the heap here, in which case, the
> object shouldn't be destroyed on the first thread unless you do it manually (in
> which case, you're doing something stupid in @system code), or you're dealing
> with passing pointers to shared value types across threads, which is
> essentially the equivalent of escaping a pointer to a local variable (in which
> case, you're doing something stupid in @system code). In either case, it's
> you're doing something stupid in @system code, and I don't see why the runtime
> would have to worry about it. You shot yourself in the foot by incorrectly
> using @system code. If you want protection agains that, then don't use @system
> code.
>
> - Jonathan M Davis
>

Thank you, thats exatcly how I'm thinking too. And because of this it 
makes absolutley no sense to me to disallow the destruction of a shared 
struct, if it is allocated on the stack or as a global. If it is 
allocated on the heap you can't destory it manually anyway because 
delete is deprecated.

And for exatcly this reason I wanted a code example from Walter. Because 
just listing a few bullet points does not make a real world use case.

Kind Regards
Benjamin Thaut