implicit conversions to/from shared

[ag0aep6g via Digitalmars-d]

On 07/11/2016 01:52 AM, Alex Parrill wrote:
> Atomic loading and storing, from what I understand, is usually limited
> to about a word on most architectures. I don't think it would be good to
> implicitly define assignment and referencing as atomic operations, since
> it would be limited. IMO concurrent access is better off being explicit
> anyway.

Simply disallow reading and writing shared then, forcing something more 
explicit like atomicLoad/atomicStore?

That would be better than the current state, but it would make shared 
even more unwieldy.

Generating atomic operations would break less code, and feels like the 
obvious thing to me. It would be kinda explicit: shared being involved 
gives it away. Also, with other forms of ensuring thread safety, you 
have to cast shared away anyway, so atomic reading/writing wouldn't be 
applied there.

> I don't think there is an issue with converting unshared reference types
> to shared (ex. ref T -> ref shared(T) or T* -> shared(T)*); worst you
> get is some extra synchronization.

shared(T)* is not shared itself, so that's fine, yeah.

I think I've approached this from the wrong angle. Implicit conversions 
are not the problem. Reading/writing is. Copying a shared value to 
another shared location is unsafe, too, if not done atomically.