Why do "const inout" and "const inout shared" exist?

[Andrei Alexandrescu via Digitalmars-d]

On 07/02/2017 09:07 AM, Timon Gehr wrote:
> On 02.07.2017 14:41, Andrei Alexandrescu wrote:
>> On 07/01/2017 07:55 PM, Timon Gehr wrote:
>>> On 02.07.2017 01:08, Andrei Alexandrescu wrote:
>>>> Vaguely related question: should "const" convert implicitly to 
>>>> "const shared"? The intuition is that the latter offers even less 
>>>> guarantees than the former so it's the more general type. See 
>>>> http://erdani.com/conversions3.svg.
>>>>
>>>> That would be nice because we have "const shared" as the unique root 
>>>> of the qualifier hierarchy.
>>>
>>> This means that there can be aliasing between an unqualified 
>>> reference and a const shared reference. Therefore, you can have code 
>>> that mutates unshared data while another thread is reading it.
>>>
>>> What should the semantics of this be?
>>>
>>> The only potential issue is that it could restrict code operating on 
>>> unshared data because it needs to play nice in some way to allow 
>>> consistent data to be read by another thread.
>>
>> Well const shared exists already with the semantics of "you can't 
>> modify this and you must load it atomically to look at it". The 
>> question is whether the conversion from const to const shared can be 
>> allowed. -- Andrei
> 
> If the data is not written atomically, how can it be loaded atomically?

Then you atomically load parts of it, the point being that the matter is 
present in the type. I must not be understanding the question. -- Andrei