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

[Stefan Koch via Digitalmars-d]

On Saturday, 1 July 2017 at 23:08:40 UTC, Andrei Alexandrescu 
wrote:
> 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

I cannot think so a single time I ever used const inout.