tuple move constructor

[Marc Glisse]

On Fri, 6 May 2016, Ville Voutilainen wrote:

> On 6 May 2016 at 20:51, Marc Glisse <marc.glisse@inria.fr> wrote:
>> Hi Ville,
>>
>> since you wrote the latest patches on tuple constructors, do you have an
>> opinion on this patch, or alternate strategies to achieve the same goal?
>>
>> https://gcc.gnu.org/ml/libstdc++/2016-04/msg00041.html
>
> I have fairly mixed feelings about the approach; it's adding a tag type 
> and more enable_ifs into the base classes of tuple, which I'd rather not 
> do unless absolutely necessary. Then again, the testcase you add looks 
> like something we want to support properly. I haven't analyzed your 
> patch in a very detailed manner; my initial thought was "can't we do 
> this in the constraints of tuple's constructors", but looking at the 
> patch and knowing the constructors of tuple, I don't think we can.

Assuming we want the copy constructor to be defaulted, I think we still 
could with concepts:

tuple(tuple const&)
requires(__and_<is_copy_constructible<_Elements>...>::value)
= default;

While there is precedent for enabling C++11 features in C++03 mode inside 
system headers, I guess maintainers might be more reluctant for something 
that is only heading for a TS for now.

> I think the patch is ok, but I think it would be a good idea to have a 
> comment on the added tag type and its purpose.

Indeed. I wasn't sure if people preferred more tags or more enable_if...

> Minor point: the technique that looks like
>
> typename enable_if<
> !is_same<_UHead, _Head>::value, bool>::type = false
>
> isn't necessary unless we have another overload that we need to
> distinguish with true/false. For a single overload,
> just using typename = typename enable_if<
> !is_same<_UHead, _Head>::value, bool>::type
> works equally well. The amount of boilerplate is more or less the
> same, so that's really not a significant matter,
> just an fyi. :)

Thanks. There are several variants on how to use enable_if, I copied one 
from some neighboring code without checking why this specific variant was 
used there.

-- 
Marc Glisse