Creating a Generic Insertion Iterator, Part 1 -- Raymond Chen
In our previous post, we created an inserter iterator for unhinted insertion, and now we’re taking it a step further by generalizing it into a boilerplate-only version. This generic output iterator allows for custom insertion logic using a lambda, but as we’ll see, it doesn’t fully satisfy iterator requirements—something we’ll attempt to fix next time.
Creating a Generic Insertion Iterator, Part 1
by Raymond Chen
From the article:
Last time, we created an inserter iterator that does unhinted insertion. We noticed that most of the iterator is just boilerplate, so let’s generalize it into a version that is all-boilerplate.
// Do not use: See discussion template<typename Lambda> struct generic_output_iterator { using iterator_category = std::output_iterator_tag; using value_type = void; using pointer = void; using reference = void; using difference_type = void; generic_output_iterator(Lambda&& lambda) : insert(std::forward<Lambda>(lambda)) {} generic_output_iterator& operator*() noexcept { return *this; } generic_output_iterator& operator++() noexcept { return *this; } generic_output_iterator& operator++(int) noexcept { return *this; } template<typename Value> generic_output_iterator& operator=( Value&& value) { insert(std::forward<Value>(value)); return *this; } protected: std::decay_t<Lambda> insert; }; template<typename Lambda> generic_output_iterator<Lambda> generic_output_inserter(Lambda&& lambda) { return generic_output_iterator<Lambda>( std::forward<Lambda>(lambda)); } template<typename Lambda> generic_output_iterator(Lambda&&) -> generic_output_iterator<Lambda>;For convenience, I provided both a deduction guide and a maker function, so you can use whichever version appeals to you. (The C++ standard library has a lot of maker functions because they predate class template argument deduction (CTAD) and deduction guides.)
C++26 will introduce senders/receivers. Lucian Radu Teodorescu demonstrates how to use them to write multithreaded code.
With C++26, the introduction of erroneous behavior provides a well-defined alternative to undefined behavior when reading uninitialized values, making it easier to diagnose and fix potential bugs. This blog post explores the impact of P2795R5, how compilers will handle erroneous values, and the new 
Contract assertions, introduced in proposal P2900 for C++26, provide a robust mechanism for runtime correctness checks, offering more flexibility and power than the traditional