Why do core.atomic functions require shared

[FeepingCreature]

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.
>
> ...
> It's a very difficult problem. Synchronized classes were 
> proposed in an attempt to solve it, but even if they were fully 
> implemented, they'd only help partially, because they can only 
> strip off the outermost layer of shared. In order for the 
> compiler to cast away shared for you, it has to be able to 
> guarantee that there are no unprotected references to that 
> data, and because D doesn't have any kind of ownership system 
> in the language, we don't have a clean way to do it.
>

Once we have DIP1000, can accessing shared class members in a 
synchronized class (optionally? implicitly?) result in scoped 
rvalues?