On 11/13/2012 1:38 AM, Sönke Ludwig wrote:
Wouldn't it be better to handle this as a special means of construction in the Unique struct, along the lines of assumeUnique()? Assuming that still most functions are still @system, this would severely limit the verification value of the Unique type otherwise.
The trouble is that templates don't work on expression ASTs, they work on types. Being able to determine if an expression is unique requires access to the expression tree, currently only the compiler can do that.
Did you see my effort on this? (http://forum.dlang.org/thread/k7orpj$1tt5$1...@digitalmars.com?page=4#post-k7rhoj:24m8h:241:40digitalmars.com) This version, instead of requiring the initialization expression to be unique, enforces that the type cannot contain non-unique references.
By operating on the expression, a lot more cases can be handled.
That is, except for shared data. Allowing shared data greatly improves its flexibility for passing data between threads. But because it guarantees that the type cannot contain non-unique data, it can allow multiple dereferences and still guarantee that no references are shared. Only immutable (or shared) references can be extracted. Everything else can only be copied or moved, keeping everything isolated.
Allowing shared access into the middle of something means that unique pointers cannot be implicitly cast to immutable.
The other trouble is doing assignments into the isolated data. What if you're assigning to a pointer, and the pointer value is pointing outside of the isolated graph?
The result is, I think, more usable because a) shared data is allowed and b) step-by-step construction of unique data is possible naturally without constantly moving a unique pointer around. What makes the C# system usable are mostly the automatic uniqueness-recovery rules, and I think those can only be implemented by the compiler (setting apart AST macros ;) ).
I think we can do this with __unique(Expression), which is not a pervasive change to the compiler, it's fairly isoloated (!). That construct would perform the "recovery". I implemented a little bit of this in NewExp::implicitConvTo().
