`<tuple>`: Should `allocator_arg_t` constructors of `tuple` specially handle `pair` since C++20?

[frederick-vs-ja]

WG21-P0591R4 (adopted in C++20) extended the definition of uses-allocator construction to cover pair. It seems that strict reading of standard wording requires the allocator_arg_t constructors of tuple to be changed.

However, no implementation is currently doing this. Example (Godbolt link):

#include <cstddef>
#include <utility>
#include <tuple>
#include <memory>
#include <vector>
#include <cassert>

template<class T>
class payload_ator {
    int payload{};
    
public:
    payload_ator() = default;

    constexpr explicit payload_ator(int n) noexcept : payload{n} {}

    template<class U>
    constexpr explicit payload_ator(payload_ator<U> a) noexcept : payload{a.payload} {}   

    friend bool operator==(payload_ator, payload_ator) = default;

    template<class U>
    friend constexpr bool operator==(payload_ator x, payload_ator<U> y) noexcept {
        return x.payload == y.payload;
    }   

    using value_type = T;

    constexpr T* allocate(std::size_t n) { return std::allocator<T>{}.allocate(n); }

    constexpr void deallocate(T* p, std::size_t n) { return std::allocator<T>{}.deallocate(p, n); }   

    constexpr int get_payload() const noexcept { return payload; }
};

bool test() {
    constexpr int in_v = 42;
    using my_pair_t = std::pair<int, std::vector<int, payload_ator<int>>>;
    std::tuple<my_pair_t> t(std::allocator_arg, payload_ator<int>{in_v});
    auto out_v = std::get<0>(t).second.get_allocator().get_payload();
    return in_v == out_v;
}

int main() {
    assert(test()); // passes only if allocator_arg_t constructors of tuple specially handle pair
}

Should we update these constructors or submit an LWG issue to avoid changing?

[StephanTLavavej]

If no implementation is doing this, then it can't be that important. Even if this is technically a bug, I'm not really eager to mess with such a critical component for such a low-value "fix".

[StephanTLavavej]

Taking a very brief glance at this, it looks like there's no hint in the tuple wording that constructor changes are necessary. There should be an LWG issue about this, following my usual principle that implementers shouldn't need to prove the Riemann Hypothesis before figuring out what needs to be implemented.

I am familiar with the wording that transforms the "ordinary" constructors into allocator_arg_t constructors, but you appear to be referring to something else here.

(Apologies if I sounded dismissive before.)

[frederick-vs-ja]

Filed LWG-4313.