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.
