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

[Timon Gehr via Digitalmars-d]

On 02.07.2017 14:31, Andrei Alexandrescu wrote:
> On 07/02/2017 02:49 AM, Shachar Shemesh wrote:
>> On 02/07/17 02: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.
>>
>> I don't see how it can. They provide different guarantees. If 
>> anything, it should be the other way around.
>>
>> If you hold a pointer to const, you know the data will not change 
>> during the function's execution. No such guarantees for const shared.
> 
> That supports the case for allowing the conversion.
> 
> const: "You have a view to data that this thread may or may not change."
> 
> const shared: "You have a view to data that any thread may or may not 
> change."
> 
> So the set of const is included in the set of const shared - texbook 
> inclusion polymorphism.

This is not the whole story. The best way to think about 'shared' is 
that it enables guarantees about data that does /not/ have the 
qualifier. So we need to look at what this change does to the meaning of 
data being unqualified:

It changes from:

unqualified: This data can be read and written exclusively by the 
current thread.

to

unqualified: This data can be read and written by this thread and read 
by any other thread.


This disallows some program transformations that were allowed before 
unless reading from a const shared reference while a mutable thread is 
writing to it has an undefined result, in which case the change just 
removes /all/ guarantees from const shared just in order to place it at 
the top of the hierarchy. At this point you can just use void*.