C++11 introduced std::function as a type-erased
callable-object holder. function is badly designed in a few ways: Its rarely used
“go fish” API bloats
every user; it advertises operator() const even when the controlled object’s operator()
is mutating; it handles what should be a precondition violation by throwing an exception,
which again bloats every user and means its operator() can never be noexcept.
So C++26 fixed these problems by adding
](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2548r6.pdf)
std::copyable_function. (copyable_function preserves some others of function’s
suboptimal design decisions: copyable_function<bool()> remains implicitly convertible
to copyable_function<void()>, contextually convertible to bool, and assignable
from nullptr.)

Authored by Arthur O'Dwyer, Quuxplusone offers  explorations of C++ programming language features, standard library design, and modern C++ development practices. Readers can delve into advanced topics such as template metaprogramming, design patterns, and effective use of language features. Additionally, they can learn about best practices for writing efficient and maintainable C++ code, optimizing performance, and leveraging the latest language standards.

Arthur O'Dwyer

C++26 introduced std::copyable_function to fix design flaws in std::function (const-correctness, exception on null call, bloated API). However, interconverting between std::function and copyable_function can silently create a 'linked list' of nested callable wrappers, causing O(n) invocation overhead and a logical memory leak after repeated round-trips. As of July 2026, libstdc++ (GCC 16) exhibits this bad behavior, while Microsoft STL avoids it for move_only_function. A benchmark demonstrates invocation time growing linearly with the number of conversions. The post also advises developers writing custom type-erased types to guard against the same wrapping pitfall via unit tests.

Interconverting std::function and copyable_function