implicit conversions to/from shared

[ag0aep6g via Digitalmars-d]

On 07/12/2016 03:51 PM, Kagamin wrote:
> It's strange if you want to expose a bare volatile variable to the rest
> of the world and expect the world to cope with concurrency on every access.

I'm not sure what you're saying here. Should unsafe reading and writing 
of shared types simply be allowed and have the common syntax (as it is 
now), and the programmer should make sure that things are set up correctly?

That's a reasonable stance, but it's not the one that D takes towards 
shared when `shared int x; ++x` is deprecated.

> The problem is when an unshared postblit is called on the shared data.

I understand that. The programmer who writes the cast would have to work 
around it. I agree that it's rather ugly. Maybe a function can be 
written that does an unsafe copy and then calls the shared postblit.

>> Correct me if I'm wrong: Currently, the compiler generates a
>> non-atomic load for reading shared data. In particular, it doesn't
>> generate a raw atomic load. And you say you can't do a raw atomic load
>> with core.atomic.atomicLoad.
>
> I say non-atomic load is not supported by atomicLoad. 5th kind of
> synchronization will help here.

So a "raw load" is just a non-atomic load after all? When I asked 
earlier you wrote "raw atomic load" in your reply, so I assumed it was 
some kind of atomic load.

Supporting non-atomic load in atomicLoad would be weird, wouldn't it? It 
would be opposite of what it says on the label.

Would the point be that it calls the shared postblit (unlike casting 
shared away and then copying)? As mentioned above, I'd hope that a 
function that does that can be written.

I didn't manage to find out what the "5th kind of synchronization" is. 
If it's important for this discussion, please elaborate.