On 6/1/15 5:50 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@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.

Andrei

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@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.

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@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

On 6/1/15 9:40 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> 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.

At language level the compiler has control over generating the destructor, so it won't if it's doing a move. Note that this is STATIC analysis. -- Andrei

On 06/01/2015 07:30 PM, Andrei Alexandrescu wrote:
> On 6/1/15 9:40 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>"
> wrote:
>> 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.
>
> At language level the compiler has control over generating the
> destructor, so it won't if it's doing a move. Note that this is STATIC
> analysis. -- Andrei

Static analysis is perfectly capable of figuring this case out. He is asking about how much sophistication will be guaranteed by the language specification, and what the exact rules are.

On 6/1/15 10:38 AM, Timon Gehr wrote:
> On 06/01/2015 07:30 PM, Andrei Alexandrescu wrote:
>> On 6/1/15 9:40 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>"
>> wrote:
>>> 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.
>>
>> At language level the compiler has control over generating the
>> destructor, so it won't if it's doing a move. Note that this is STATIC
>> analysis. -- Andrei
>
> Static analysis is perfectly capable of figuring this case out. He is
> asking about how much sophistication will be guaranteed by the language
> specification, and what the exact rules are.

It should be enough to do the move only if all paths of execution end in the same conversion to rvalue. -- Andrei

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
My last year's thoughts about that:
https://issues.dlang.org/show_bug.cgi?id=13492

On 01/06/15 06:43, Andrei Alexandrescu via Digitalmars-d 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

Having just been playing with noncopyable types at the suggestion of Dicebot, Steve Schweighoffer and Martin Nowak, thanks for drawing attention to this.  I can see it being very useful to address.

On Mon, 01 Jun 2015 11:03:29 +0000, Namespace wrote:

> What about ----
> auto h = &r.front; // can get the front of the range ----
> ?

there is funnier trick:
  static void testfront(T) (auto ref T n) {} testfront(r.front);

the thing is that we don't really want to check if we can take an address of front value, we want to keep `ref` if it's there. with this magic template `ref` is not stripped, but we still don't require "&" to work.