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

[via Digitalmars-d]

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:
>>> FYI I just created 
>>> https://issues.dlang.org/show_bug.cgi?id=14638 as
>>> one of possibly several language enhancements to improve 
>>> usability of
>>> noncopyable types (most allocators are not copyable) and to 
>>> enhance
>>> performance of objects that define this(this). -- Andrei
>>
>> What do "static use" and "dynamic use" mean here?
>
> static = as you read the code
> dynamic = as you run the code
>
>> 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.