DIP49 - Define qualified postblit

[Timon Gehr]

On 11/10/2013 07:46 AM, Kenji Hara wrote:
> http://wiki.dlang.org/DIP49
>
> Experimental compiler/druntime patches (WIP, 80% completed):
> https://github.com/9rnsr/dmd/tree/qual_pblit
> https://github.com/9rnsr/druntime/tree/qual_pblit
>
> Kenji Hara

Well written DIP!

- Rules [c1] and [c5] are unsound and should be removed.

const(int)[] constglobal;

struct S{
     int[] arr;
     this(this)const{
         arr = constglobal;
     }
}

int[] coerceC1Unsound(const(int)[] g){
     constglobal = g;
     S s;
     S t=s;
     // ... (any code that makes the above invoke postblit)
     return t.arr;
}

immutable(int)[] coerceC5Unsound(const(int)[] g){
     constglobal = g;
     S s;
     immutable(S) t=s;
     // ... (ditto)
     return t.arr;
}

- Typo in immutable postblit description: "You can regard the [i2] case
   as that the generated immutable copy is referred by const reference."
   Should read: "You can regard the [i1] case ..."

- Unique postblit:
  = The general concept seems useful, but what about this case:

struct S{
     int[] a; // should be shared between all copies
     int[] b; // should be cloned across copies

     this(this)/+same qualifier on source and target+/{
         b = b.dup;
     }
}

void main(){
     S s;
     immutable(S) t;
     auto g = s;
     auto h = t;
     // ...
}

  = Do you think that in this case one should implement identical
    mutable and immutable postblit?

  = "Pure function call which returns unique object"
    -> "Strongly pure ..."

  = "New expression with unique arguments"
    -> "Pure new expression ..."

  = (Also, the inadequacy of 'inout' becomes painfully obvious: Clearly,
    we'd want 'inout' to mean something different for the source and
    target struct instances. Then the definition of what is unique
    would not be necessary in this DIP. (Anything that converts to inout
    would be fine anyway.))