Bug 6922 – [TDPL] superimposing of const and immutable does not work correctly

From TDPL, p. 299: "When two qualifiers are superimposed, D uses simple composition rules. If the qualifiers are identical, they are collapsed into one. Otherwise, const(immutable(T)) and immutable(const(T)) are both collapsed into immutable(T) because that is the most informative type." However, with DMD 2.056: static assert(is(immutable(const(T)) == immutable(T))); // fail. static assert(is(const(immutable(T)) == immutable(const(T)))); // fail. static assert(is(const(immutable(T)) == immutable(T))); // fail. All three assertions should pass.

*** Issue 6338 has been marked as a duplicate of this issue. ***

From discussion in https://github.com/D-Programming-Language/dmd/pull/505 1. inout + const of T should parse [1a] const(T) or [1b] inout(T)? 2. or introduce new combined qualifier inout(const(T))? (see bug 6930) Current my patch have selected [1a] as the result.

(In reply to comment #3) > From discussion in https://github.com/D-Programming-Language/dmd/pull/505 > > 1. inout + const of T should parse [1a] const(T) or [1b] inout(T)? > 2. or introduce new combined qualifier inout(const(T))? (see bug 6930) > > Current my patch have selected [1a] as the result. Parsing it as inout(T) or parsing it as const(T) is both wrong (and any of the two are an arbitrary choice). The 'definition' of inout is that it is whatever qualifier is on the input argument. Consider the type inout(const(T)) We can now make a case distinction: 1. inout == mutable => inout(const(T)) == const(T) 2. inout == const => inout(const(T)) == const(const(T)) == const(T) 3. inout == immutable => inout(const(T)) == immutable(const(T)) == immutable(T) Option 1. does not support the 3rd case, therefore it is wrong. Option 2. works as expected, therefore it is correct. I do not think there is a choice. (adding unnecessary special cases is the way to make a language ugly and complicated, see C++) If you disagree, with what part of the explanation do you disagree?

(In reply to comment #4) > If you disagree, with what part of the explanation do you disagree? No, I don't disagree your explanation. My only argument is that is *debatable* thing. OK. I'll change my patch to make the combination of inout and const ambiguous (== keep current behavior) in order to make room for improvement.

(In reply to comment #5) > (In reply to comment #4) > > If you disagree, with what part of the explanation do you disagree? > > No, I don't disagree your explanation. My only argument is that is *debatable* > thing. Apparently it is. :o) > > OK. I'll change my patch to make the combination of inout and const ambiguous > (== keep current behavior) in order to make room for improvement. Thank you.

*** Issue 6855 has been marked as a duplicate of this issue. ***