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

[Timon Gehr via Digitalmars-d]

On 02.07.2017 01:08, Andrei Alexandrescu wrote:
> 
> Thanks! Well I do want to have a hierarchy with all possible qualifier 
> combinations for utmost clarity. Only the combinations listed are valid, 
> e.g. there's no "immutable inout" or whatever.
> ...

immutable(inout(T)) is valid syntax, but this type is equal to immutable(T).

> 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.