Re: [boost] [variant] Please vote for behavior

Subject: Re: [boost] [variant] Please vote for behavior
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-02-08 15:09:24

on Thu Feb 07 2013, Emil Dotchevski <emildotchevski-AT-gmail.com> wrote:

> On Thu, Feb 7, 2013 at 6:57 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>>
>> on Thu Feb 07 2013, Michael Marcin <mike.marcin-AT-gmail.com> wrote:
>>
>>> Sebastian Redl wrote:
>>>>
>
>>>> On 07.02.2013, at 21:25, Dave Abrahams wrote:
>>>>
>>>>>
>>>>> on Thu Feb 07 2013, Sebastian Redl <sebastian.redl-AT-getdesigned.at> wrote:
>>>
>>>>>
>>>>>> On 06.02.2013, at 22:10, Dave Abrahams wrote:
>>>>>>
>>>>>>>
>>>>>>> on Sat Feb 02 2013, Sebastian Redl <sebastian.redl-AT-getdesigned.at> wrote:
>>>>>>>
>>>>>>>> Anything that gives the target object the state the source object had
>>>>>>>> and is cheaper than a copy is a successful move, really. That is what
>>>>>>>> a move ultimately is: an optimization of copying.
>>>>>>>
>>>>>>> I never liked that characterization.  If move were an optimization of
>>>>>>> copy it would have all the semantics of copy...
>>>>>>
>>>>>> I disagree. That would be the case if move were a universally
>>>>>> applicable optimization, but it isn't. It's a special case
>>>>>> optimization. In intent, it optimizes copying for the case where the
>>>>>> resulting state of the source object is irrelevant. In practice, the
>>>>>> source object must retain some valid state.
>>>>>>
>>>>>> This is really similar to how the compiler can only apply some
>>>>>> optimizations if it can prove certain properties of the code,
>>>>>> e.g. that two pointers don't alias (various redundant load or store
>>>>>> eliminations) or that a piece of code is side effect free (loop
>>>>>> fusion, common subexpression elimination).
>>>>>
>>>>> Yes, but those are semantics-preserving transformations.  I suppose you
>>>>> can call move an optimization if you presume the irrelevancy of the
>>>>> source object has been proven, but usually that proof is part of the
>>>>> optimization process.
>>>>
>>>> That's why move only implicitly kicks in for rvalues and return of
>>>> local lvalues, where this has indeed been proven. (Sort of. It's
>>>> actually not true for local lvalues, but then, copy elision can
>>>> change visible behavior too.)
>>>> For lvalues, where the compiler can't (or won't) prove it, user
>>>> intervention is required in the form of std::move. Think of it like
>>>> of the restrict qualifier for aliasing.
>>>
>>> I don't see how move is an optimization of copy since you can move
>>> noncopyable types.
>>
>> Yeah, that's another thing.
>
> Is the compiler even allowed to choose between copy and move? 

On the basis of whether a move exists, yes.  On the basis of whether a
copy exists, no.

> My understanding is that you can't tell it "this type can't be copied
> so if I've told you to copy, see if you can move instead".

I think it wouldn't be too hard to code up a copy_else_move(x) function
along the same lines as std::move(x).  You'd probably use some trait to
detect copiability.

-- 
Dave Abrahams