In analogy to library defect 811, tuple's variadic constructor

template <class... UTypes>
explicit tuple(UTypes&&... u);

creates the same problem as pair:

#include <tuple>

int main()
{
  std::tuple<char*> p(0);
}

produces a similar compile error for a recent gcc implementation.

I suggest to follow the same resolution path as has been applied to pair's corresponding c'tor, that is require that these c'tors should not participate in overload resolution, if the arguments are not implicitly convertible to the element types.

Further-on both pair and tuple provide converting constructors from different pairs/tuples that should be not available, if the corresponding element types are not implicitly convertible. It seems astonishing that in the following example

struct A {
  explicit A(int);
};

A  a = 1; // Error

std::tuple<A> ta = std::make_tuple(1); // # OK?

the initialization marked with # could be well-formed.