Issue 2549: Tuple EXPLICIT constructor templates that take tuple parameters end up taking references to temporaries and will create dangling references

Title: Tuple EXPLICIT constructor templates that take tuple parameters end up taking references to temporaries and will create dangling references
Status: c++17
Section: [tuple.cnstr]
Submitter: Ville Voutilainen

Created on 2015-10-11.00:00:00 last changed 89 months ago

Messages

msg8001 (view)

Date: 2016-03-05.10:50:33

Proposed resolution:

This wording is relative to N4567.

This approach is orthogonal to the Proposed Resolution for LWG 2312:
1. Edit [tuple.cnstr] as indicated:
```
template <class... UTypes> EXPLICIT constexpr tuple(const tuple<UTypes...>& u);
```
 […]
 -17- Remarks: This constructor shall not participate in overload resolution unless
 - is_constructible<T_i, const U_i&>::value is true for all i, and
 - sizeof...(Types) != 1, or (when Types... expands to T and UTypes... expands to U) !is_convertible_v<const tuple&, T> && !is_constructible_v<T, const tuple&> && !is_same_v<T, U> is true.
 The constructor is explicit if and only if is_convertible<const U_i&, T_i>::value is false for at least one i.
```
template <class... UTypes> EXPLICIT constexpr tuple(tuple<UTypes...>&& u);
```
 […]
 -20- Remarks: This constructor shall not participate in overload resolution unless
 - is_constructible<T_i, U_i&&>::value is true for all i, and
 - sizeof...(Types) != 1, or (when Types... expands to T and UTypes... expands to U) !is_convertible_v<tuple, T> && !is_constructible_v<T, tuple> && !is_same_v<T, U> is true.
 The constructor is explicit if and only if is_convertible<U_i&&, T_i>::value is false for at least one i.
This approach is presented as a merge with the parts of the Proposed Resolution for LWG 2312 with overlapping modifications in the same paragraph, to provide editorial guidance if 2312 would be accepted.
1. Edit [tuple.cnstr] as indicated:
```
template <class... UTypes> EXPLICIT constexpr tuple(const tuple<UTypes...>& u);
```
 […]
 -17- Remarks: This constructor shall not participate in overload resolution unless
 - sizeof...(Types) == sizeof...(UTypes), and
 - is_constructible<T_i, const U_i&>::value is true for all i, and
 - sizeof...(Types) != 1, or (when Types... expands to T and UTypes... expands to U) !is_convertible_v<const tuple&, T> && !is_constructible_v<T, const tuple&> && !is_same_v<T, U> is true.
 The constructor is explicit if and only if is_convertible<const U_i&, T_i>::value is false for at least one i.
```
template <class... UTypes> EXPLICIT constexpr tuple(tuple<UTypes...>&& u);
```
 […]
 -20- Remarks: This constructor shall not participate in overload resolution unless
 - sizeof...(Types) == sizeof...(UTypes), and
 - is_constructible<T_i, U_i&&>::value is true for all i, and
 - sizeof...(Types) != 1, or (when Types... expands to T and UTypes... expands to U) !is_convertible_v<tuple, T> && !is_constructible_v<T, tuple> && !is_same_v<T, U> is true.
 The constructor is explicit if and only if is_convertible<U_i&&, T_i>::value is false for at least one i.

msg7988 (view)

Date: 2016-03-05.10:50:33

[ 2016-03, Jacksonville ]

STL provides a simplification of Ville's alternative #2 (with no semantic changes), and it's shipping in VS 2015 Update 2.

msg7576 (view)

Date: 2016-02-15.00:00:00

[ 2016-02-17, Ville comments ]

It was pointed out at gcc bug 69853 that the fix for LWG 2549 is a breaking change. That is, it breaks code that expects constructors inherited from tuple to provide an implicit base-to-derived conversion. I think that's just additional motivation to apply the fix; that conversion is very much undesirable. The example I wrote into the bug report is just one example of a very subtle temporary being created.

Previous resolution from Ville [SUPERSEDED]:

Alternative 1:
In [tuple.cnstr]/17, edit as follows:
template <class... UTypes> EXPLICIT constexpr tuple(const tuple<UTypes...>& u);
[…]
-17- Remarks: This constructor shall not participate in overload resolution unless

is_constructible<T_i, const Ui&>::value is true for all i., and

sizeof...(Types) != 1, or is_convertible<const tuple<UTypes...>&, Types...>::value is false and is_constructible<Types..., const tuple<UTypes...>&>::value is false.

[Note: to avoid infinite template recursion in a trait-based implementation for the case where UTypes... is a single type that has a constructor template that accepts tuple<Types...>, implementations need to additionally check that remove_cv_t<remove_reference_t<const tuple<UTypes...>&>> and tuple<Types...> are not the same type. — end note]
The constructor is explicit if and only if is_convertible<const U_i&, T_i>::value is false for at least one i.
In [tuple.cnstr]/20, edit as follows:
template <class... UTypes> EXPLICIT constexpr tuple(tuple<UTypes...>&& u);
[…]
-20- Remarks: This constructor shall not participate in overload resolution unless

is_constructible<T_i, U_i&&>::value is true for all i., and

sizeof...(Types) != 1, or is_convertible<tuple<UTypes...>&&, Types...>::value is false and is_constructible<Types..., tuple<UTypes...>&&>::value is false.

[Note: to avoid infinite template recursion in a trait-based implementation for the case where UTypes... is a single type that has a constructor template that accepts tuple<Types...>, implementations need to additionally check that remove_cv_t<remove_reference_t<tuple<UTypes...>&&>> and tuple<Types...> are not the same type. — end note]
The constructor is explicit if and only if is_convertible<U_i&&, T_i>::value is false for at least one i.
Alternative 2 (do the sameness-check normatively):
In [tuple.cnstr]/17, edit as follows:
template <class... UTypes> EXPLICIT constexpr tuple(const tuple<UTypes...>& u);
[…]
-17- Remarks: This constructor shall not participate in overload resolution unless

is_constructible<T_i, const Ui&>::value is true for all i., and

sizeof...(Types) != 1, or is_convertible<const tuple<UTypes...>&, Types...>::value is false and is_constructible<Types..., const tuple<UTypes...>&>::value is false and is_same<tuple<Types...>, remove_cv_t<remove_reference_t<const tuple<UTypes...>&>>>::value is false.

The constructor is explicit if and only if is_convertible<const U_i&, T_i>::value is false for at least one i.
In [tuple.cnstr]/20, edit as follows:
template <class... UTypes> EXPLICIT constexpr tuple(tuple<UTypes...>&& u);
[…]
-20- Remarks: This constructor shall not participate in overload resolution unless

is_constructible<T_i, U_i&&>::value is true for all i., and

sizeof...(Types) != 1, or is_convertible<tuple<UTypes...>&&, Types...>::value is false and is_constructible<Types..., tuple<UTypes...>&&>::value is false and is_same<tuple<Types...>, remove_cv_t<remove_reference_t<tuple<UTypes...>&&>>>::value is false.

The constructor is explicit if and only if is_convertible<U_i&&, T_i>::value is false for at least one i.

msg7575 (view)

Date: 2015-10-11.00:00:00

Consider this example:

#include <utility>
#include <tuple>

struct X {
  int state; // this has to be here to not allow tuple
             // to inherit from an empty X.
  X() {
  }

  X(X const&) {
  }

  X(X&&) {
  }

  ~X() {
  }
};

int main()
{
  X v;
  std::tuple<X> t1{v};
  std::tuple<std::tuple<X>&&> t2{std::move(t1)}; // #1
  std::tuple<std::tuple<X>> t3{std::move(t2)}; // #2
}

The line marked with #1 will use the constructor template <class... UTypes> EXPLICIT constexpr tuple(tuple<UTypes...>&& u); and will construct a temporary and bind an rvalue reference to it. The line marked with #2 will move from a dangling reference.

In order to solve the problem, the constructor templates taking tuples as parameters need additional SFINAE conditions that SFINAE those constructor templates away when Types... is constructible or convertible from the incoming tuple type and sizeof...(Types) equals one. libstdc++ already has this fix applied.

There is an additional check that needs to be done, in order to avoid infinite meta-recursion during overload resolution, for a case where the element type is itself constructible from the target tuple. An example illustrating that problem is as follows:

#include <tuple>

struct A
{
  template <typename T>
  A(T)
  {
  }

  A(const A&) = default;
  A(A&&) = default;
  A& operator=(const A&) = default;
  A& operator=(A&&) = default;
  ~A() = default;
};

int main()
{
  auto x = A{7};
  std::make_tuple(x);
}

I provide two proposed resolutions, one that merely has a note encouraging trait-based implementations to avoid infinite meta-recursion, and a second one that avoids it normatively (implementations can still do things differently under the as-if rule, so we are not necessarily overspecifying how to do it.)

History
Date	User	Action	Args
2017-07-30 20:15:43	admin	set	status: wp -> c++17
2016-06-28 12:47:21	admin	set	status: ready -> wp
2016-03-08 22:51:25	admin	set	status: new -> ready
2016-03-05 10:50:33	admin	set	messages: + msg8001
2016-02-21 14:37:47	admin	set	messages: + msg7988
2015-10-20 17:58:16	admin	set	messages: + msg7576
2015-10-11 00:00:00	admin	create