On Wednesday, 6 February 2013 at 18:15:53 UTC, Dan wrote:
Assume you want value semantics - postblit provides this
capability. It appears with 2.061 'this(this) const' is now
supported. Previously, only 'this(this)' was recognized (I.e.
called) when expected. To get value semantics a developer must
choose between these two and for this case the goal is to
ensure 'c = c.dup;' so value semantics are preserved.
Hmmm... in my mind 'this(this) const' would both referring prior
to postblit, so mainly to pointers and arrays (not POD
post-copy). That would only be to ensure the original data
doesn't change in some unexpected way. In that way also postblit
acts as an initializer so 'const' doesn't come into play until
the field changes for the first time.
I considered that perhaps the writing was wrong and it would be
'this(const this)', however since this is a variable it's
referring to the hidden first field who's type is automatically
deduced. This means it can't be that way otherwise all the data
is const and thereby the definition is disallowed (pointless),
unless you'd wanted to only change something from the original
array... which seems off.
So an example to consider:
struct S {
int[] x;
const(int)[] y;
const z;
this(this) {
x[0] = 1; //edits previous array
y[0] = 1; //y's contents are const
this.x = this.x.dup; //new array for x & y
this.y = this.y.dup;
x[0] = 2; //after new array
// y[0] = 2; //y's contents are const
z = 100; //allowed one change
}
this(this) const {
x[0] = 1; //Error: Previous 'this' is const and cannot change
y[0] = 1; //y's contents are const
this.x = this.x.dup; //new array for x & y
this.y = this.y.dup;
x[0] = 2; //allowed
// y[0] = 2; //y's contents are const
z = 100; //allowed one change
}
}
