tuple move constructor

[Marc Glisse]

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


On Thu, 21 Apr 2016, Marc Glisse wrote:

> On Thu, 21 Apr 2016, Jonathan Wakely wrote:
>
>> On 20 April 2016 at 21:42, Marc Glisse wrote:
>>> Hello,
>>> 
>>> does anyone remember why the move constructor of _Tuple_impl is not
>>> defaulted? The attached patch does not cause any test to fail (whitespace
>>> kept to avoid line number changes). Maybe something about tuples of
>>> references?
>> 
>> I don't know/remember why. It's possible it was to workaround a
>> front-end bug that required it, or maybe just a mistake and it should
>> always have been defaulted.
>
> Ok, then how about something like this? In order to suppress the move
> constructor in tuple (when there is a non-movable element), we need to
> either declare it with suitable constraints, or keep it defaulted and
> ensure that we don't bypass a missing move constructor anywhere along
> the way (_Tuple_impl, _Head_base). There is a strange mix of 2
> strategies in the patch, I prefer the tag class, but I started using
> enable_if before I realized how many places needed those horrors.
>
> Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
>
>
> 2016-04-22  Marc Glisse  <marc.glisse@inria.fr>
>
> 	* include/std/tuple (__element_arg_t): New class.
> 	(_Head_base(const _Head&), _Tuple_impl(const _Head&, const 
> _Tail&...):
> 	Remove.
> 	(_Head_base(_UHead&&)): Add __element_arg_t argument...
> 	(_Tuple_impl): ... and adjust callers.
> 	(_Tuple_impl(_Tuple_impl&&)): Default.
> 	(_Tuple_impl(const _Tuple_impl<other>&),
> 	_Tuple_impl(_Tuple_impl<other>&&), _Tuple_impl(_UHead&&): Constrain.
> 	* testsuite/20_util/tuple/nomove.cc: New.

-- 
Marc Glisse