The C++20 Concept Trap of std::inserter and std::array

[Jimmy-Hu]

When writing a generic function template that populates an output container—using std::inserter for dynamic containers (std::vector, std::deque, std::list) and falling back to overwriting elements via std::ranges::begin for fixed-size containers (std::array<T, N>)—it is natural to reach for a C++20 concept and if constexpr.

However, combining C++98 iterator adaptors (std::inserter) with C++20 requires-expressions creates a subtle two-layer trap.

Attempt 1: Checking if std::inserter can be constructed

The first instinct is to check whether std::inserter(x, std::ranges::end(x)) is a valid expression:

template<typename T>
concept naive_is_inserterable = requires(T& x)
{
    std::inserter(x, std::ranges::end(x));
};

Surprisingly, naive_is_inserterable<std::array<int, 4>> evaluates to true!
Because std::inserter only constructs a std::insert_iterator<T> proxy object (storing a pointer to the container and an iterator), it never checks whether .insert() exists during construction. When std::array enters the if constexpr branch for std::inserter, it triggers a hard compilation error ('insert': is not a member of 'std::array<...>') inside the algorithm body as the following pseudocode:

template<std::ranges::input_range Range>
void foo(Range& container)
{
    if constexpr (naive_is_inserterable<Range>)
    {
        // Passes std::inserter(container, ...) to an algorithm (which invokes container.insert()).
        // If Range is std::array<int, 4>, this branch will still be instantiated and fail to compile!
    }
    else
    {
        // Fallback for fixed-size containers
    }
}

Attempt 2: Simulating element assignment (*std::inserter(...) = v)

Since the actual .insert() call lives inside std::insert_iterator::operator=, the next logical step is to simulate an assignment inside the requires-expression:

template<typename T>
concept assign_is_inserterable =
    std::ranges::range<T> and
    requires(T& x, std::ranges::range_value_t<T> v)
    {
        *std::inserter(x, std::ranges::end(x)) = v;
    };

Counter-intuitively, assign_is_inserterable<std::array<int, 4>> still evaluates to true! Why?

1. Unevaluated Operands ([expr.prim.req]): Expressions inside a requires block are unevaluated. The compiler only checks whether the member function declaration of std::insert_iterator<T>::operator= matches the argument types in the immediate context—it does not instantiate the body of operator=.
2. Non-Deduced Return Type & Unconstrained Signature: Because std::insert_iterator::operator=(const typename Container::value_type&) has an explicit, non-auto return type (insert_iterator&) and lacks a C++20 requires clause of its own, the compiler never inspects its function body (container->insert(iter, value)) during concept satisfaction checks. Since std::array provides both iterator and value_type, the declaration signature matches cleanly.

The Fix: Verifying x.insert(...) in the Immediate Context

To force the compiler to verify insertion capability during concept evaluation, we must query x.insert(...) directly on the container alongside std::inserter:

template<typename T>
concept is_inserterable =
    std::ranges::range<T> and
    requires(T& x, std::ranges::range_value_t<T> v)
    {
        x.insert(std::ranges::end(x), v);
        std::inserter(x, std::ranges::end(x));
    };

With this direct check, is_inserterable<std::array<int, 4>> properly evaluates to false.
(Context: We encountered this while unifying multi-level container transformations in TinyDIP::recursive_transform so that mixed nested structures like std::vector<std::array<T, N>> can be transformed in a single template function.)

Minimal Reproducible Example

#include <algorithm>
#include <array>
#include <cassert>
#include <concepts>
#include <cstdlib>
#include <iostream>
#include <iterator>
#include <ranges>
#include <vector>

namespace TinyDIP
{
    // Attempt 1: Only checks if std::inserter can be constructed
    template<typename T>
    concept naive_is_inserterable = requires(T& x)
    {
        std::inserter(x, std::ranges::end(x));
    };

    // Attempt 2: Simulates assignment (*std::inserter(...) = v)
    // Still evaluates to true for std::array!
    template<typename T>
    concept assign_is_inserterable =
        std::ranges::range<T> and
        requires(T& x, std::ranges::range_value_t<T> v)
        {
            *std::inserter(x, std::ranges::end(x)) = v;
        };

    // The Fix: Verify x.insert(...) directly in the immediate context
    template<typename T>
    concept is_inserterable =
        std::ranges::range<T> and
        requires(T& x, std::ranges::range_value_t<T> v)
        {
            x.insert(std::ranges::end(x), v);
            std::inserter(x, std::ranges::end(x));
        };

    // Minimal generic function demonstrating the if constexpr dispatch
    template<typename OutputContainer, std::ranges::input_range InputRange>
    constexpr OutputContainer populate_doubled(const InputRange& input)
    {
        OutputContainer output{};
        auto double_op = [](const auto val)
        {
            return val * 2;
        };

        if constexpr (is_inserterable<OutputContainer>)
        {
            std::ranges::transform(
                input,
                std::inserter(output, std::ranges::end(output)),
                double_op
            );
        }
        else
        {
            std::ranges::transform(
                input,
                std::ranges::begin(output),
                double_op
            );
        }
        return output;
    }
}

int main()
{
    using FixedArray = std::array<int, 4>;

    // 1. Compile-time verification of the two traps vs. the fix
    static_assert(TinyDIP::naive_is_inserterable<FixedArray> == true);
    static_assert(TinyDIP::assign_is_inserterable<FixedArray> == true);
    static_assert(TinyDIP::is_inserterable<FixedArray> == false);

    std::cout << "Concept evaluation for std::array<int, 4>:\n"
              << "  Attempt 1 (naive_is_inserterable)  : "
              << std::boolalpha << TinyDIP::naive_is_inserterable<FixedArray> << '\n'
              << "  Attempt 2 (assign_is_inserterable) : "
              << std::boolalpha << TinyDIP::assign_is_inserterable<FixedArray> << '\n'
              << "  The Fix   (is_inserterable)        : "
              << std::boolalpha << TinyDIP::is_inserterable<FixedArray> << "\n\n";

    // 2. Test unified dispatch on both std::array and std::vector
    constexpr FixedArray source{ 1, 2, 3, 4 };
    constexpr auto arr_result = TinyDIP::populate_doubled<FixedArray>(source);
    const auto vec_result = TinyDIP::populate_doubled<std::vector<int>>(source);

    assert(arr_result[3] == 8);
    assert(vec_result[3] == 8);

    std::cout << "Populated std::array<int, 4> : [ ";
    for (const int v : arr_result)
    {
        std::cout << v << ' ';
    }
    std::cout << "]\n";

    std::cout << "Populated std::vector<int>   : [ ";
    for (const int v : vec_result)
    {
        std::cout << v << ' ';
    }
    std::cout << "]\n";

    return EXIT_SUCCESS;
}

Godbolt Link

Discussion Questions

1. Should C++ standard library implementations (or a future defect report) constrain std::insert_iterator::operator= and std::back_insert_iterator::operator= on the underlying container operations (insert, push_back), or would that break valid legacy code?

2. How do you prefer to structure insertion traits when writing generic functions that support both dynamic containers and std::array?