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

[Andrei Alexandrescu via Digitalmars-d]

On 07/01/2017 06:12 PM, Timon Gehr wrote:
> On 01.07.2017 23:47, Andrei Alexandrescu wrote:
>> Walter looked at http://erdani.com/conversions.svg and said actually 
>> "const inout" and "const inout shared" should not exist as distinct 
>> qualifier groups, leading to the simplified qualifier hierarcy in 
>> http://erdani.com/conversions-simplified.svg.
>>
>> Are we missing something?
> 
> I don't think so.
> 
>> Is there a need for combining const and inout?
>> ...
> 
> In DMD's implementation, yes. (Combinations of qualifiers are 
> represented as integers instead of nested AST nodes.)
> 
> const(const(T))     = const(T)
> const(immutable(T)) = immutable(T)
> const(inout(T))     = ?
> 
> It used to be the case that const(inout(T)) = const(T), but this is 
> wrong, because if we replace 'inout' by 'immutable', the result should 
> be immutable(T), not const(T). Hence const(inout(T)) cannot be reduced 
> further.
> 
> The simplified hierarchy is enough though. The more complex one can be 
> derived from it. Since S -> const(S) for all S, it directly follows that 
> inout(T) -> const(inout(T)) for all T (we can choose S=inout(T)).

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.

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.


Andrei