DIP53 and DIP49 (ver2) - New definitions for qualified constructors and postblits

[Timon Gehr]

On 12/20/2013 08:43 AM, Joseph Rushton Wakeling wrote:
> On 20/12/13 01:41, deadalnix wrote:
>> If that is an extra learning cost, doesn't it make the semantic more
>> complex,
>> almost by definition ?
>
> Compared to ... ?
>
> As far as I can see, it's learning a small extra meaning of 'const' in a
> context where it's quite intuitive,  ...

It is not only adding an extra meaning of const, but also removing an 
old one in some specific context. Why is the following 'intuitive'?

const(int*) g = ...;

struct S{
     int* a, b;
     this(immutable(int)* a, immutable(int)* b)immutable{
         this.a=a; // ok
         this.b=b; // ok
     }
     this(const(int)* a, const(int)* b)const{
         this.a=a; // error
         this.b=b; // error
     }
     // if we want to initialize a and b with pointers
     // with different qualifiers, we can do the following
     this(inout(int)* a, inout(int)* b)inout{
         this.a=a; // ok
         this.b=b; // ok
     }
     // but in general, initializing a field with a
     // 'const' reference is not fair game in such
     // a constructor
     this(inout(int)* a)inout{
         this.a=a;
         this.b=g; // error
     }
}

Why is it 'intuitive' that in this context 'inout' is not a wildcard for 
the other type qualifiers?

struct S{
     int* a, b;
     this(inout(int)* a, inout(int)* b)inout{
         this.a=a;
         this.b=b;
     }
     // no go:
     // this(const(int)* a, const(int)* b)const{this.a=a; this.b=b; }
}
// ...
// but:
int* a = ...;
immutable(int)* b=...;
auto s = S(a,b); // ok!
static assert(is(typeof(s)==const(S)));

The DIP breaks some existing, perfectly valid code without any clear way 
to fix it.

const(int)* foo(...){ ... }

class C{
     int* a;
     this()const{
         a = foo(...); // error
     }
}


Again, what is so 'intuitive' about this?