Issue 6922 - [TDPL] superimposing of const and immutable does not work correctly
Summary: [TDPL] superimposing of const and immutable does not work correctly
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P2 normal
Assignee: No Owner
URL:
Keywords: patch, rejects-valid
: 6338 6855 (view as issue list)
Depends on:
Blocks:
 
Reported: 2011-11-09 14:23 UTC by timon.gehr
Modified: 2011-12-11 19:34 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description timon.gehr 2011-11-09 14:23:36 UTC 
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.
Comment 1 Kenji Hara 2011-11-10 01:42:21 UTC 
*** Issue 6338 has been marked as a duplicate of this issue. ***
Comment 3 Kenji Hara 2011-11-10 12:48:18 UTC 
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.
Comment 4 timon.gehr 2011-11-10 12:57:55 UTC 
(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?
Comment 5 Kenji Hara 2011-11-10 13:10:16 UTC 
(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.
Comment 6 timon.gehr 2011-11-10 13:14:59 UTC 
(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.
Comment 8 Kenji Hara 2011-12-11 19:34:35 UTC 
*** Issue 6855 has been marked as a duplicate of this issue. ***