Opportunities for D

[Nick Treleaven via Digitalmars-d]

On 10/07/2014 19:03, Walter Bright wrote:
> On 7/10/2014 9:00 AM, Nick Treleaven wrote:
>> On 09/07/2014 20:55, Walter Bright wrote:
>>>    Unique!(int*) u = new int;   // must work
>>
>> That works, it's spelled:
>>
>> Unique!int u = new int;
>
> I'm unconfortable with that design, as T can't be a class ref or a
> dynamic array.

It does currently work with class references, but not dynamic arrays:

     Unique!Object u = new Object;

It could be adjusted so that all non-value types are treated likewise:

     Unique!(int[]) v = [1, 3, 2];

>>>    int* p = new int;
>>>    Unique!(int*) u = p;         // must fail
>>
>> The existing design actually allows that, but nulls p:
>  > [...]
>> If there are aliases of p before u is constructed, then u is not the
>> sole owner
>> of the reference (mentioned in the docs):
>> http://dlang.org/phobos-prerelease/std_typecons.html#.Unique
>
> Exactly. It is not checkable and not good enough.

In that case we'd need to deprecate Unique.this(ref RefT p) then.

> Note that as of 2.066 the compiler tests for uniqueness of an expression
> by seeing if it can be implicitly cast to immutable. It may be possible
> to do that with Unique without needing compiler modifications.

Current Unique has a non-ref constructor that only takes rvalues. Isn't 
that good enough to detect unique expressions?

>> Also related is whether we use alias this to expose the resource
>> (allowing
>> mutation but not replacement) or if we use opDispatch. Currently, it
>> uses opDot,
>> which AFAICT is basically opDispatch. If we use alias this, that's
>> a(nother)
>> hole exposing non-unique access to the resource.
>
> The holes must be identified and closed.

OK, opDispatch then.

> BTW, I'm amenable to adjusting the compiler to recognize Unique and help
> out as a last resort.