Better handling of noncopyable objects and objects with this(this)

[Jonathan M Davis via Digitalmars-d]

On Monday, 1 June 2015 at 16:40:38 UTC, Marc Schütz wrote:
> On Monday, 1 June 2015 at 15:45:11 UTC, Andrei Alexandrescu 
> wrote:
>> On 6/1/15 5:50 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
>> <schuetzm at gmx.net>" wrote:
>>> On Monday, 1 June 2015 at 04:43:20 UTC, Andrei Alexandrescu 
>>> wrote:
>>> Also, object with destructors need to have more restrictions:
>>>
>>>    S {
>>>        ~this();
>>>    }
>>>
>>>    void foo() {
>>>        S s;
>>>        if(condition)
>>>            bar(s);
>>>        // <- should we run the destructor here?
>>>    }
>>>
>>> This can either be solved by making such cases non-eligible, 
>>> or by
>>> "remembering" whether an object was moved using a hidden 
>>> boolean
>>> variable. AFAIK the latter is incidentally the solution Rust 
>>> chose.
>>
>> This has been solved, we have move which obliterates the 
>> source with .init.
>
> Huh? What does that have to do with the current topic?
>
> The question is not what should happen when someone does a 
> conditional _explicit_ move, but whether a move should be done 
> _implicitly_ by the compiler given the above constellation, and 
> how it deals with the destructor if yes.

Obviously, only Andrei can say for sure what he meant, but I 
would guess that he was suggesting that in the case of

if(condition)
    bar(s);

it would set s to S.init when it's moved for the call to bar so 
that the destructor can be run when s exits scope regardless of 
which branch was executed - though that does mean that the 
destructor is run twice when bar(s) is called (once inside of Bar 
for the original value and once for the init value) - so while 
that solution is correct and straightforward, I'm not sure that 
it's the best one.

- Jonathan M Davis