`<utility>`: Is extending triviality for `pair` and `tuple` on the list of improvements for vNext?

[cristi1990an]

static_assert(std::is_trivially_copy_assignable_v<std::tuple<int, int>>); // fails
static_assert(std::is_trivially_copy_constructible_v<std::tuple<int, int>>); // fails
static_assert(std::is_trivially_copy_assignable_v<std::pair<int, int>>); // fails
static_assert(std::is_trivially_copy_constructible_v<std::pair<int, int>>); // passes

Current the implementation of pair and tuple is not trivially copy constructible and assignable when their underlying types are, which I assume hinders performance and certain optimizations - which is a shame since they should be zero cost abstractions. Implementing this improvement is an obvious ABI break and I believe it would require rewriting a big chunk of the tuple implementation. I was wondering if this improvement is considered in the vNext abi break - I know tuple compresssion of empty types is, but I haven't seen any discurssion on this.

[frederick-vs-ja]

For tuple, I think it should be made trivially copyable in vNext whenever eligible. See this comment:

STL/stl/inc/tuple

Line 214 in 52e35aa

constexpr tuple(const tuple&) noexcept /* strengthened */ {} // TRANSITION, ABI: should be defaulted

But I'm a bit not sure whether this is planned for pair.

[StephanTLavavej]

pair already has defaulted copy/move ctors:

STL/stl/inc/utility

Lines 277 to 278 in 52e35aa

	pair(const pair&) = default;
	pair(pair&&) = default;

As @frederick-vs-ja noted, the empty tuple's copy ctor (and therefore all non-empty tuples) is marked for vNext. This one is ABI-critical, in that I tried to default it, broke bincompat, and had to revert it while adding this comment. (It affected how things are passed in registers; the break was really bad and diagnosing it was a huge headache.)

For assignment operators, we need to deal with pair and tuple's unwise design decision to handle references. I think with modern constraints we could probably make them vanish for non-reference types so they could be defaulted, but that could take some work.

I'll label this issue for vNext followup.