C++23 gave std::optional and std::expected monadic operations - and_then, transform, or_else and transform_error for std::expected. The pattern is clearly useful. But it is not extensible: every type that wants to participate must wait for the committee to add member functions. std::unique_ptr, raw owning pointers, third-party expected types, user-defined result wrappers - none of them participate in the same vocabulary.
std::optional
std::expected
and_then
transform
or_else
transform_error
std::unique_ptr
During Library in a Week at C++Now 2025, I proposed beman.monadics: free-function monadic operations for any "box-like type." The idea is to define a uniform extensibility interface so that raw pointers, smart pointers, and user-defined wrappers can participate in the same monadic pipeline as std::expected - without waiting for the committee to add member functions to each one.
beman.monadics
The central question is whether monadic operations should be treated as algorithms or as customization points and the answer is not obvious. Each approach implies a different extensibility mechanism, different concept requirements, and a different path to standardization. This talk works through the design space: what makes a type "box-like" and how to express that as a concept, how to handle types that have a value but no error channel, and what a uniform pipe syntax requires from the constraint model.
C++Now 2025 started this. C++Now 2026 is the right place to find out if it can be finished.
View Slides
Mikhail is a Principal Software Engineer at reMarkable, where he writes C++ for hardware that may or may not have an operating system.
At Library in a Week at C++Now 2025, he proposed beman.monadics: free-function monadic operations for any box-like type. This talk is what happened next.
His interests are libraries that should compose but don't, build systems that should be declarative but aren't, and compile-time computation that arguably goes further than it should. He has been writing C++ for over 15 years.