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.))
