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

[Andrei Alexandrescu via Digitalmars-d]

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