2013/11/10 Timon Gehr <timon.gehr@gmx.ch>
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!

Thank you!
 
- 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;
}

Oops... Indeed [c1] and c5] may break type system... I deleted these rules from the DIP.
 
- 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 ..."

Thanks. Fixed. 

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

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

This is valid. Because not only strongly pure function will return unique object.

For example:
  immutable(int)[] foo(int[] iarr) pure { ... }
  int[] marr = foo([1,2,3]);
  // foo will never return the arr argument (without unsafe cast).
 
 = "New expression with unique arguments"
   -> "Pure new expression ..."

I'm not sure that "pure new expression" is widely used word in D...
 
 = (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.))

As I already answered to deadalnix,  it is strongly related to inout.
To describe about that, I added a section "Why use 'inout' keyword for 'unique' postblit?" in DIP.

Kenji Hara