On 2013-05-12, 11:50, deadalnix wrote:

> On Sunday, 12 May 2013 at 09:10:56 UTC, Simen Kjaeraas wrote:
>> On 2013-05-12, 08:12, deadalnix wrote:
>>
>>> On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:
>>>> I'm not convinced. unique, like const or immutable, is transitive. If foo
>>>> is unique, then so is foo.bar.
>>>>
>>>
>>> That isn't true. Please read microsoft's paper.
>>
>> Done. *Mostly* transitive, then. Anything reachable through a unique
>> reference is either unique or immutable.
>
> No.
>
> Think about it : when you reach something via a uniq pointer, it is by definition not unique as you have 2 copies of it, because you just accessed it.
>
> Plus the unique pointer refers to a unique mutable graph of object. A object into that graph can have several object into the graph refereing to it.
>
> You are wrong in 2 different ways.

I'd argue it's only one way, if only to reduce the impact to my ego. :p

Yes, you're absolutely right. Anything reachable through a unique
reference needs to be *lent* or immutable. That way, it's either safe
to create new references to it, or the type system forbids it.

-- 
Simen

You may wish to take a look at Rust for inspiration. Rust has unique (~) pointers and has made some interesting choices there. Their ~pointers imply ownership. I'm not sure this could be (efficiently) duplicated in a library for D (Rust has significant compiler support for its pointer types) but it may be worth taking a look regardless.

On 5/12/13 5:10 AM, Simen Kjaeraas wrote:
> On 2013-05-12, 08:12, deadalnix wrote:
>
>> On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:
>>> I'm not convinced. unique, like const or immutable, is transitive. If
>>> foo
>>> is unique, then so is foo.bar.
>>>
>>
>> That isn't true. Please read microsoft's paper.
>
> Done. *Mostly* transitive, then. Anything reachable through a unique
> reference is either unique or immutable.

Bartosz, Walter and I reached a similar design a few years ago. We just thought it complicates things too much for what it does.

Andrei

On 5/12/13 5:50 AM, deadalnix wrote:
> On Sunday, 12 May 2013 at 09:10:56 UTC, Simen Kjaeraas wrote:
>> On 2013-05-12, 08:12, deadalnix wrote:
>>
>>> On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:
>>>> I'm not convinced. unique, like const or immutable, is transitive.
>>>> If foo
>>>> is unique, then so is foo.bar.
>>>>
>>>
>>> That isn't true. Please read microsoft's paper.
>>
>> Done. *Mostly* transitive, then. Anything reachable through a unique
>> reference is either unique or immutable.
>
> No.
>
> Think about it : when you reach something via a uniq pointer, it is by
> definition not unique as you have 2 copies of it, because you just
> accessed it.

I don't think so. Lent and destructive read can be used.

> Plus the unique pointer refers to a unique mutable graph of object. A
> object into that graph can have several object into the graph refereing
> to it.

Correct.


Andrei

On Sunday, 12 May 2013 at 13:07:15 UTC, Andrei Alexandrescu wrote:
> On 5/12/13 5:50 AM, deadalnix wrote:
>> On Sunday, 12 May 2013 at 09:10:56 UTC, Simen Kjaeraas wrote:
>>> On 2013-05-12, 08:12, deadalnix wrote:
>>>
>>>> On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:
>>>>> I'm not convinced. unique, like const or immutable, is transitive.
>>>>> If foo
>>>>> is unique, then so is foo.bar.
>>>>>
>>>>
>>>> That isn't true. Please read microsoft's paper.
>>>
>>> Done. *Mostly* transitive, then. Anything reachable through a unique
>>> reference is either unique or immutable.
>>
>> No.
>>
>> Think about it : when you reach something via a uniq pointer, it is by
>> definition not unique as you have 2 copies of it, because you just
>> accessed it.
>
> I don't think so. Lent and destructive read can be used.
>

Destructive read would be super confusing and due to the Correct point below, don't ensure anything.

>> Plus the unique pointer refers to a unique mutable graph of object. A
>> object into that graph can have several object into the graph refereing
>> to it.
>
> Correct.
>

On 5/12/2013 6:01 AM, Andrei Alexandrescu wrote:
> Bartosz, Walter and I reached a similar design a few years ago. We just thought
> it complicates things too much for what it does.

I've been working in the background on a scheme that can infer uniqueness. The beauty of it is it will not require visible language changes - it's just that things that didn't compile before now will. It won't solve all the problems, but I'm hoping it'll solve enough that the rest will not be more than a minor annoyance.

For a trivial example,

    shared p = new int;

would work, as 'new int' would be inferred to be unique, and a unique pointer can be implicitly cast to immutable or shared. This plays to D's strength with function purity, transitive const/immutable/shared, attribute inference, etc.

13-May-2013 00:28, Walter Bright пишет:
> On 5/12/2013 6:01 AM, Andrei Alexandrescu wrote:
>> Bartosz, Walter and I reached a similar design a few years ago. We
>> just thought
>> it complicates things too much for what it does.
>
> I've been working in the background on a scheme that can infer
> uniqueness. The beauty of it is it will not require visible language
> changes - it's just that things that didn't compile before now will.

Good things these are, but that adds up to what a programmer should know or we are stuck trying out combinations that might work until we hit it.


-- 
Dmitry Olshansky

On 5/12/2013 1:48 PM, Dmitry Olshansky wrote:
> 13-May-2013 00:28, Walter Bright пишет:
>> On 5/12/2013 6:01 AM, Andrei Alexandrescu wrote:
>>> Bartosz, Walter and I reached a similar design a few years ago. We
>>> just thought
>>> it complicates things too much for what it does.
>>
>> I've been working in the background on a scheme that can infer
>> uniqueness. The beauty of it is it will not require visible language
>> changes - it's just that things that didn't compile before now will.
>
> Good things these are, but that adds up to what a programmer should know or we
> are stuck trying out combinations that might work until we hit it.

I think programmers will find it to be intuitive, not magical.

13-May-2013 02:47, Walter Bright пишет:
> On 5/12/2013 1:48 PM, Dmitry Olshansky wrote:
>> 13-May-2013 00:28, Walter Bright пишет:
>>> On 5/12/2013 6:01 AM, Andrei Alexandrescu wrote:
>>>> Bartosz, Walter and I reached a similar design a few years ago. We
>>>> just thought
>>>> it complicates things too much for what it does.
>>>
>>> I've been working in the background on a scheme that can infer
>>> uniqueness. The beauty of it is it will not require visible language
>>> changes - it's just that things that didn't compile before now will.
>>
>> Good things these are, but that adds up to what a programmer should
>> know or we
>> are stuck trying out combinations that might work until we hit it.
>
> I think programmers will find it to be intuitive, not magical.
>

By the end of day we need guarantees not intuition which is the problem.

Compare the statement in the would be standard of D:
"If the compiler can prove that the expression is unique it's implicitly convertible to shared/immutable/const."
vs
"The following rules define what kinds of if the expression is unique. [...] Unique expression is convertible to shared/immutable/const."

The keyword "the compiler can prove" - it doesn't state anything reliable. In the long run I'd prefer the second and exact formal rules and if they are too hard to explain we'd better not do it at all.

-- 
Dmitry Olshansky

On 5/12/2013 11:11 PM, Dmitry Olshansky wrote:
> In the long run I'd prefer the second and exact formal rules and if they are too
> hard to explain we'd better not do it at all.


I agree that formal rules are better. I'm working on it.