Opportunities for D

[Andrei Alexandrescu via Digitalmars-d]

On 7/10/14, 10:56 AM, Walter Bright wrote:
> On 7/10/2014 6:55 AM, Andrei Alexandrescu wrote:
>> On 7/10/14, 12:21 AM, Walter Bright wrote:
>>> On 7/10/2014 12:03 AM, deadalnix wrote:
>>>> So runtime error or php style better anything than nothing for
>>>> something that
>>>> can be checked statically...
>>>
>>> I don't understand your comment.
>>
>> It's very simple. The semantics you propose is move with the syntax of
>> copy.
>> Following the implicit move, the source of it is surprisingly modified
>> (emptied).
>
> Right, that is what I proposed.
>
>> That doesn't work. There is a humongous body of knowledge accumulated
>> in C++
>> with std::auto_ptr. That artifact has been quite the show, including
>> people who
>> swore by it (!). We'd do good to simply draw from that experience
>> instead of
>> reenacting it.
>
> I accept that you're right, but I don't know why. I perused the link you
> provided earlier, and wasn't too enlightened.
>
> It was clear from those links that unique_ptr<T> is working successfully
> - what is different about that?

We discussed this with Bartosz literally for weeks (him being a fan of 
auto_ptr for too long, later completely converted against it and I take 
credit for that :o)). With auto_ptr this was possible:

auto_ptr<int> a(new int);
auto_ptr<int> b = a;

It would nullify a with copy syntax. That code won't compile with 
unique_ptr; you'd need an explicit move(a).

It only got worse from there: passing into functions, member variables...

MOVING WITH COPY SYNTAX DOES NOT WORK.

It's cut and dried.


Andrei