Why do core.atomic functions require shared

[Boris-Barboris]

On Wednesday, 4 July 2018 at 10:47:12 UTC, Jonathan M Davis wrote:
> At this point, to operate on anything that's shared, either 
> means using atomics or protecting the data with a mutex (be 
> that with a synchronized block / function or a mutex object) 
> and temporarily casting away shared while operating on the 
> data. Afterwards, the mutex is released, and at that point, 
> there should just be only shared references to the data. About 
> the only time that operating directly on a shared object then 
> makes sense is when it manages the atomics or mutex and 
> associated cast internally.

Good overview. Some syntactic sugar should ease the casting pain, 
because it's the casting that I dislike the most, especially wheh 
shared has to be casted away from multiple unrelated entities 
guarded by one mutex chain or some high-level synchronization 
rule, unknown to the compiler. If there would be a construct that 
does not involve additional line of code and explicit type 
specification (or some typeof + Unqual shenanigans), I would 
probably have no problem with this approach. Currently, the 
casting seems to be the correct way, and it's far from 
user-friendly. Maybe such thing should not be a cast at all, and 
some kind of built-in property, idk.