On 4/10/2015 4:18 PM, Martin Nowak wrote:
> On 04/10/2015 11:29 PM, Walter Bright wrote:
>>
>> The latter.
>
> Can you update that part in the DIP, it wasn't clear that the temporary
> selectively pins RCO fields of a normal struct passed by ref.
>

It pins RCO objects, however they are derived.

On Friday, 10 April 2015 at 15:44:32 UTC, Andrei Alexandrescu wrote:
> We hope to do better than Rust. -- Andrei

Hope does not cut it.

A design that breaks down even on a linked list (e.g. you have to turn to ref-counted pointers everywhere) and that makes findByRef(container,node) break should not have made it to a DIP in the first place.

D needs clean semantics on what is a value. The only sensible definition for a copyable value is that you cannot take the identity in _any way_ from a value or anything that can be reached from it.

D needs clean semantics on what is unique ownership. Ref counting is not it. Pervasive ref counting requires WPO to work out ok.

C++14 with sanitizer tooling is a lot more attractive than this direction you are going for.

On Friday, 10 April 2015 at 21:26:14 UTC, Walter Bright wrote:
> This would be a bad design of an RCO. RCO's must be constructed to not allow pointers to the payload other than by ref.

And taking the address of that is already unsafe.

I was thinking about this again, and how the first 'ref' would create a copy in order to keep the object around. At first I thought I didn't like that, but then I realised that it's actually not far from what I wanted for taking r-values by reference. I commonly write functions which take values either by reference or by value in this way.

void foo(ref T value);
void foo(T value) { foo(value); }

Which obviously results in a combinatorial explosion of overloads, which you can write automatically some times with 'auto ref'.

My question is, in the greater context of the language, supposing we had this copying behaviour for a first ref for reference counted objects, will it putting something in the language for copying r-values into functions, or will it provide a path to implement such a thing?

On Friday, 10 April 2015 at 21:26:14 UTC, Walter Bright wrote:
> On 4/10/2015 11:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>> Example:
>>
>> void foo() @safe {
>>     RCArray!int arr = [0,1,2];
>>     {
>>         int* p = &arr[0];  // legal under new scope rules
>
> This would be a bad design of an RCO. RCO's must be constructed to not allow pointers to the payload other than by ref.

There is no reason for this restriction. But if this is your opinion, why did you agree to "implement 'scope' and 'return' for arrays, classes, and pointers"?

http://forum.dlang.org/post/mfhkbm$2vbk$1@digitalmars.com

It makes no sense to implement that, but not allow it to be used safely.

On Saturday, 11 April 2015 at 09:15:19 UTC, Martin Nowak wrote:
> On Friday, 10 April 2015 at 21:26:14 UTC, Walter Bright wrote:
>> This would be a bad design of an RCO. RCO's must be constructed to not allow pointers to the payload other than by ref.
>
> And taking the address of that is already unsafe.

It isn't under my proposal, which Walter has already accepted the most important part of.

On Friday, 10 April 2015 at 23:12:55 UTC, deadalnix wrote:
> On Friday, 10 April 2015 at 10:02:01 UTC, Martin Nowak wrote:
>> On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
>>> http://wiki.dlang.org/DIP77
>>
>> So someone passes an RCO via ref to avoid the inc/dec, and because that imposes safety issues we turn it into some sort of pass by value under the hood, defeating the purpose, and provide an opt-out via @system opAssign.
>>
>> Wouldn't it more straightforward to make pass-by-ref unsafe (@system) for RCOs?
>>
>> Then the only thing missing to make this equally powerful, would be an optimization opportunity for the compiler to elide copies of pass-by-value RCOs, e.g. it could avoid calling the postblit when the function retains the refcount.
>
> Only the first pass by ref create a copy. You can then pass the ref down all you want without copy.
>
> That is an acceptable cost IMO.

It's not acceptable that it happens behind the user's back. Costly operations must be explicit.

On 4/11/2015 2:18 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Friday, 10 April 2015 at 21:26:14 UTC, Walter Bright wrote:
>> On 4/10/2015 11:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>>> Example:
>>>
>>> void foo() @safe {
>>>     RCArray!int arr = [0,1,2];
>>>     {
>>>         int* p = &arr[0];  // legal under new scope rules
>>
>> This would be a bad design of an RCO. RCO's must be constructed to not allow
>> pointers to the payload other than by ref.
>
> There is no reason for this restriction.

The reason is to prevent unsafe access of the payload.


> But if this is your opinion, why did
> you agree to "implement 'scope' and 'return' for arrays, classes, and pointers"?
>
> http://forum.dlang.org/post/mfhkbm$2vbk$1@digitalmars.com
>
> It makes no sense to implement that, but not allow it to be used safely.

In your example posted upthread, it wasn't safe. Perhaps scoped pointers can't be made safe for RCOs, or perhaps the proposal needs more thinking. I don't know at the moment.

On 4/11/2015 2:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> It's not acceptable that it happens behind the user's back. Costly operations
> must be explicit.

Don't know of a better solution.

On Saturday, 11 April 2015 at 08:35:18 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 10 April 2015 at 15:44:32 UTC, Andrei Alexandrescu wrote:
>> We hope to do better than Rust. -- Andrei
>
> Hope does not cut it.
>
> A design that breaks down even on a linked list (e.g. you have to turn to ref-counted pointers everywhere) and that makes findByRef(container,node) break should not have made it to a DIP in the first place.

a bidirectional linked list cannot be implemented in safe rust afaik