ccc错误“试图在具有右值的元组中构造参考元素”，gcc未给出

Question

I've written the following (relatively) simple implementation of a std::tuple zip function (analogous to Python's zip ) with perfect forwarding:

template <size_t I, size_t N>
struct tuple_zip_helper {
  template <typename... Tuples>
  constexpr auto operator()(Tuples&&... tuples) const {
    return tuple_cat(
      make_tuple( forward_as_tuple(get<I>(forward<Tuples>(tuples))...) ),
      tuple_zip_helper<I+1, N>()(forward<Tuples>(tuples)...)
    );
  }
};

template <size_t N>
struct tuple_zip_helper<N, N> {
  template <typename... Tuples>
  constexpr auto operator()(Tuples&&...) const {
    return forward_as_tuple();
  }
};

namespace std {
  // Extend min to handle single argument case, for generality
  template <typename T>
  constexpr decltype(auto) min(T&& val) { return forward<T>(val); }
}

template <typename... Tuples>
auto tuple_zip(Tuples&&... tuples) {
  static constexpr size_t min_size = min(tuple_size<decay_t<Tuples>>::value...);
  return tuple_zip_helper<0, min_size>()( forward<Tuples>(tuples)... );
}

This appears to work fine for two or more tuples, even when mixing lvalues and rvalues and even when I use a BlabberMouth class to check for spurious copies and moves:

template <typename Tuple>
void f(Tuple&& tup) {
  cout << get<0>(get<0>(tup)).data << endl;
}

struct Blabbermouth {
  Blabbermouth(string const& str) : data(str) { }
  Blabbermouth(Blabbermouth const& other) : data(other.data) { cout << data << " copied" << endl; }
  Blabbermouth(Blabbermouth&& other) : data(move(other.data)) { cout << data << " moved" << endl; }
  string data;
};

int main(int argc, char** argv) {
  Blabbermouth x("hello ");
  // prints "hello"
  f(tuple_zip(
      forward_as_tuple(x, 2),
      forward_as_tuple(Blabbermouth("world"), 3)
  ));
}

It also works fine when I give it just one tuple without mixing lvalues and rvalues (clang-3.9, earlier versions of clang choke on this as well):

f(tuple_zip( forward_as_tuple(Blabbermouth("world"), 3) ));  // prints "world"

However, when I mix lvalues and rvalues and only give one tuple, clang freaks out about something in a noexecpt specification (but gcc is fine, and even runs correctly):

auto x = BlabberMouth("hello");
f(tuple_zip( forward_as_tuple(x, 3) ));  // clang freaks out, gcc okay

Live Demo

What (if anything) am I doing wrong? Should gcc be complaining, or should clang not be complaining? Does my code have any dangling references that I'm just "getting lucky" with, and that's why clang is objecting? Should I have done this differently? If clang is the one wrong here, can anyone suggest a workaround? (And/or link me to a bug report?)

---

Update

@Oktalist contributed a much more minimal example that illustrates the same problem:

struct foo {};

int main(int argc, char** argv)
{
  foo f;
  std::tuple<foo&> t(f);
  std::tuple_cat(std::make_tuple(t), std::make_tuple());
}

(I had considered making my example more minimal as well, but I wasn't sure if what I was doing was exactly analogous to this, mainly because I don't fully understand how perfect forwarding interacts with auto / decltype(auto) return values, return value optimization (RVO), std::get and std::make_tuple , so I wanted to be sure I wasn't doing something else stupid.)

Answer 1

The bug is caused by the calls to tuple_cat (though not exactly in it; it seems to be some messiness inside libc++'s tuple 's byzantine maze of constructors and SFINAE conditions), so the workaround is to avoid using it.

There is no point in doing recursive tuple_cat s anyway; one pack expansion (or two) will do.

template<size_t I, typename... Tuples>
constexpr auto tuple_zip_one(Tuples&&... tuples) {
    return forward_as_tuple(get<I>(forward<Tuples>(tuples))...);
}

template<size_t...Is, typename... Tuples>
constexpr auto tuple_zip_helper(index_sequence<Is...>, Tuples&&... tuples) {
    return make_tuple(tuple_zip_one<Is>(forward<Tuples>(tuples)...)...);
}

template <typename... Tuples>
auto tuple_zip(Tuples&&... tuples) {
  static constexpr size_t min_size = min({tuple_size<decay_t<Tuples>>::value...});
  return tuple_zip_helper( make_index_sequence<min_size>(), forward<Tuples>(tuples)... );
}

I took the liberty of removing your UB-inducing min overload and simply using the standard initializer_list version instead.

Demo .