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?
