Immutable and unique in C#

[Walter Bright]

On 11/12/2012 11:48 PM, Sönke Ludwig wrote:
> Am 13.11.2012 00:46, schrieb Walter Bright:
>> On 11/9/2012 5:53 AM, Sönke Ludwig wrote:
>>> Independent of this article I think D is currently missing out a lot by
>>> omitting a proper unique type (a _proper_ library solution would be a
>>> start, but I'm not sure if that can handle all details). It would make a
>>> lot of the cases work that are currently simply not practical because of
>>> loads of casts that are necessary.
>>
>> Unique as a type qualifier comes with all kinds of subtle problems. For one thing, unique is more of
>> a property of an expression rather than a property of the type.
>>
>> But I was thinking - what if it's a storage class? Like ref is? Working through the use cases in my
>> head, I think it can work. Unique being a property of an expression, this can be tested upon
>> assignment to the unique variable. Upon reading that unique variable, the value of it is erased.
>>
>> Function parameters can be qualified with "unique" as well, meaning their corresponding arguments
>> can only be unique expressions.
>>
>
> Currently I also see no reason why this should not be possible. Since it is acting recursively and
> locally anyway, a storage class will probably capture almost everything that a full type would. I
> had thought about the same route to reduce intrusiveness, before looking first what's possible with
> a pure library solution.
>
> The library solution seems surprisingly practical for some use cases. With the concept of "string"
> and "weak" isolation (*), it can even handle the bridge between isolated and shared memory (thanks
> to the completely separated nature of shared). By this, it solves a lot of the problems that only
> Bartosz system was able to solve, for example declaring owned collections (no Mutex necessary),
> which contain references to shared data, and still everything is safely checked.
>
> A proper language feature can still do a lot more and IMO D should get there at some point - but I
> think this is a viable short/mid-term alternative. I would like to get some discussion going to
> eventually include something in phobos.
>
>
> (*)
>
> strong isolation: allows only strongly isolated and immutable references
>   -> can be passed to other threads and casts implicitly to immutable
>
> weak isolation: allows weakly isolated, immutable and shared references
>   -> can only be passed to other threads
>

I've thought some more about it, and there are some implementation problems with 
doing it as a storage class. Specifically, the issue of enforcing destructive 
reads from unique variables, which is a very intrusive and complex change for 
little gain.

However, this is not an issue if, instead, we created:

    Unique!T v = ...;

where T is a pointer/class type. It's a wrapper around T with some interesting 
properties. Unique!T can be implemented to only allow one, destructive, read. 
All that read does is return a value of type T.

A Unique!T can only be initialized by:

    1. a destructive read of another instance of Unique!T
    2. an expression that can be determined to generated an isolated pointer

#2 is the interesting bit. That requires some compiler support, sort of like:

      __unique(Expression)

which will allow it through if Expression is some combination of new, pure 
functions, and other Unique pointers.

There is also the issue of "I know it's a unique pointer, but the compiler 
cannot guarantee that, so how do I set it?" for which I propose that in @system 
functions, __unique(Expression) always says it's ok.

Note that dereferencing a Unique!T variable will always entail a destructive 
read of it. Therefore, multiple reads will require storing it into an instance 
of T. Calling a method with a Unique!T this will also require converting it into 
a T. Getting it back into a Unique!T will require some @system programming.


P.S. Yes, I know there's std.typecons.Unique, but it has a lot of holes in it, 
such as:

     &up.a.b;   // uh-oh, now we have another address
                // into the supposedly isolated graph!