http://wiki.dlang.org/DIP77

On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP77

Deceptively simple solution for a hard problem.

On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP77

That is pretty much the old Rust solution called boxing. This sound like the right way forward to me.

On 4/8/2015 5:30 PM, deadalnix wrote:
> On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
>> http://wiki.dlang.org/DIP77
>
> That is pretty much the old Rust solution called boxing. This sound like the
> right way forward to me.

Yes, it's equivalent to it. I had started with doing an INC/DEC pair, but that implied adding more logic to detect how to do an INC/DEC for a particular type. The logic for doing a copy is much more straightforward. The RC object should also be designed in such a way that the copy is not costly.

Function purity is again showing what an advantage it is.

Andrei's idea was to not do the copy for @system opAssign's, thus providing C++ equivalence for those folks that need it and don't care about guaranteed memory safety.

On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP77

Can this be clarified a little?
>The lifetime of tmp will be the same as that of a temporary with a destructor.

Does that mean the lifetime of tmp is tied to the scope of the function being called, or the current scope calling the function?

On Thursday, 9 April 2015 at 00:30:46 UTC, deadalnix wrote:
> On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
>> http://wiki.dlang.org/DIP77
>
> That is pretty much the old Rust solution called boxing. This sound like the right way forward to me.

Any idea why they abandoned it?

On 4/8/2015 6:19 PM, Brad Anderson wrote:
> On Thursday, 9 April 2015 at 00:30:46 UTC, deadalnix wrote:
>> On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
>>> http://wiki.dlang.org/DIP77
>>
>> That is pretty much the old Rust solution called boxing. This sound like the
>> right way forward to me.
>
> Any idea why they abandoned it?

No, but I can guess. It's less efficient.

On 4/8/2015 5:49 PM, weaselcat wrote:
> On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
>> http://wiki.dlang.org/DIP77
>
> Can this be clarified a little?
>> The lifetime of tmp will be the same as that of a temporary with a destructor.
>
> Does that mean the lifetime of tmp is tied to the scope of the function being
> called, or the current scope calling the function?

The same as that of a tmp being returned from a function - to the end of the expression.

On Thursday, 9 April 2015 at 01:35:14 UTC, Walter Bright wrote:
> On 4/8/2015 6:19 PM, Brad Anderson wrote:
>> On Thursday, 9 April 2015 at 00:30:46 UTC, deadalnix wrote:
>>> On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
>>>> http://wiki.dlang.org/DIP77
>>>
>>> That is pretty much the old Rust solution called boxing. This sound like the
>>> right way forward to me.
>>
>> Any idea why they abandoned it?
>
> No, but I can guess. It's less efficient.

This and the fact that they want to prevent multiple writable burrow for concurrency reasons, so that seemed like the correct way forward for them.

On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP77

I've only skimmed this, but:

1. I don't think Objective-C uses autorelease pools for any other reason than to make manual ref counting easier.

See also John McCall's reflections on ARC:

http://forum.dlang.org/thread/mcqcor$aa$1@digitalmars.com?page=2#post-hgmhgirfervrsvcghchw:40forum.dlang.org

2. How will this work with "yield"?

Why not just implement the more generic solution (shared pointers with move/borrow or WPO) ?