const(X) member of Y

[Era Scarecrow]

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
    }
  }