https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> --- > Standard says that if: > std::is_constructible_v<Bar, Foo&&> > then > std::is_constructible_v<std::tuple<Bar>, Foo&&> Where does it say that? The fact a constructor participates in overload resolution doesn't mean it has to be well-formed for all template arguments. > So I think this is not an instance of PR 82113, but an unfortunate > consequence of how tuple is implemented in libstdc++. If tuple elements were > not stored as base classes, but as members than elision is mandatory and it > would work. Members using [[no_unique_address]] have the same restrictions. > But I guess to fix this you would have to break ABI (or change C++ standard). It wouldn't be an ABI break to make this compile with our std::tuple, because it never compiled previously. But I'm a little uncomfortable with making the ABI of std::tuple depend on whether its elements are copy constructible, rather than just on the elements' layout. That would mean that std::tuple<Bar> changes layout if you later add a move constructor to Bar.
