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