C++23 Code Capsules
Mathematicians and programmers alike have always known that functions are things you can do things with, not just things you call. One of the most natural operations on functions is composition: given f and g, form the new function (f ∘ g) where (f ∘ g)(x) = f(g(x)). Chain enough of these together and you have a pipeline — a sequence of transformations applied one after another.
Functional programmers have known this for decades. In Standard ML, folding a list of functions over an initial value is idiomatic and concise:
(* ML: apply a list of functions right-to-left *)
fun compose fs x = foldr (fn (f, acc) => f acc) x fs
foldr
processes the list from the right, threading an
accumulator through each function in turn. The result is function
composition expressed as a fold — (f_1(f_2(...f_n(x)...))) — and the
combining function takes (element, accumulator)
in right-to-left order.
C++, being based on a procedural language that put performance first,
took a longer road to arrive at the same idea. But arrive it did. This
capsule traces that journey across three standards, building a reusable
Composer
class that grows cleaner at each step.
Here is a first cut, written in C++17:
// Makes the function type generic
#include <algorithm>
#include <functional>
#include <iostream>
#include <numeric>
#include <vector>
using namespace std;
template<typename Fun>
class Composer {
vector<Fun>& funs;
public:
Composer(vector<Fun>& fs) : funs(fs) {}
using T = typename Fun::result_type;
T operator()(T x) const {
auto apply = [](T sofar, Fun f){ return f(sofar); };
return accumulate(rbegin(funs), rend(funs), x, apply);
}
};
struct g {
double operator()(double x) { return x * x; }
};
int main() {
auto f = [](double x){ return x / 2.0; };
using Fun = function<double(double)>;
vector<Fun> funs{f, g(), [](double x){ return x + 1.0; }};
Composer<Fun> comp(funs);
cout << comp(2.0) << "\n"; // 4.5
using Fun2 = function<string(const string&)>;
vector<Fun2> funs2{
[](const string& s){ return s + "s"; },
[](const string& s){ return s + "'"; }
};
Composer<Fun2> comp2(funs2);
cout << comp2("Vernor") << "\n"; // Vernor's
}
The core of the class is this line:
return accumulate(rbegin(funs), rend(funs), x, apply);
Walking the vector in reverse and folding left is equivalent to
folding right — it applies the last function first, then the
second-to-last, and so on. This is exactly ML’s foldr
in
disguise, expressed through std::accumulate
and reversed iterators. It works, but the disguise is unfortunate: the intent is a right fold, but it isn’t crystal clear in the code.
There is also a more practical problem. Composer
is
parameterized on the function type Fun
, and it
extracts the value type via Fun::result_type
. That member
only exists on std::function
, not on raw lambdas or
function objects. The
using Fun = function<double(double)>
in
main
is not incidental — it is required. The class forces its clients to wrap their callables.
C++20 does not change the algorithm, but it invites a rethinking of the interface. The right abstraction for single-valued functions is not “a composer parameterized on a function type” — it is “a composer parameterized on a value type.” The functions are an implementation detail; what matters to the caller is the type they are transforming.
Flipping the template parameter from Fun
to
T
gives us this:
template<typename T>
class Composer {
vector<function<T(T)>> funs;
public:
Composer(vector<function<T(T)>> fs) : funs(move(fs)) {}
T operator()(T x) const {
auto apply = [](T acc, auto f){ return f(acc); };
return accumulate(rbegin(funs), rend(funs), x, apply);
}
};
Now main
reads naturally:
Composer<double> comp({ ... });
Composer<string> comp2({ ... });
Composer<double>
means what it says: a composition
of functions on double
. The std::function
wrapping still happens, but it is now an internal detail of the class,
not something the caller needs to explicitly name. C++20 concepts could
further constrain T
(to require copyability, say, or to express the same input as output type requirement), but for a capsule of this size the improvement in readability already tells the story.
C++23 brings two things that complete the picture:
std::ranges::fold_right
, and a usable implementation of
modules. (I’ll admit that this problem is small enough to not
require a module; in fact Composer
could be a part of a larger module, but indulge me here. :-)
fold_right
replaces the
accumulate(rbegin, rend, ...)
idiom with something that names its intent directly:
T operator()(T x) const {
return std::ranges::fold_right(funs, x, [](auto f, auto acc){ return f(acc); });
}
Notice the argument order in the lambda:
(element, accumulator)
. This is the same order as ML’s
foldr
combining function —
fn (f, acc) => f acc
. That is not a coincidence. C++ has absorbed the idea, and the interface reflects it.
The full module interface file:
// composer.cppm
export module composer;
import std;
export template<typename T>
class Composer {
std::vector<std::function<T(T)>> funs;
public:
Composer(std::vector<std::function<T(T)>> fs) : funs(std::move(fs)) {}
T operator()(T x) const {
return std::ranges::fold_right(funs, x, [](auto f, auto acc){ return f(acc); });
}
};
And the test driver that consumes it:
// compose23.cpp
import composer;
import std;
int main() {
Composer<double> comp({
[](double x){ return x / 2.0; },
[](double x){ return x * x; },
[](double x){ return x + 1.0; }
});
std::cout << comp(2.0) << "\n"; // 4.5
Composer<std::string> comp2({
[](std::string s){ return s + "s"; },
[](std::string s){ return s + "'"; }
});
std::cout << comp2("Vernor") << "\n"; // Vernor's
}
Composer
is a natural fit for a module: it is
self-contained, has no platform dependencies, and exports exactly one
thing. The import std;
in the test driver replaces a half-dozen headers. The result is as clean as the class deserves.
We started with a right fold expressed as accumulate
over reversed iterators — a correct but oblique encoding of an idea that
ML stated directly in the 1970s. Over three standards, C++ acquired the
vocabulary to say the same thing clearly: a value-typed interface, a
named fold_right
, a module boundary that packages the abstraction for reuse.
This is the direction modern C++ has been moving for some time.
Ranges, folds, std::function
, concepts, modules — these are not disconnected features. They are the pieces of a language that is gradually adopting powerful ideas in its own idiom, an idiom that has had a sometimes-hard-to-follow syntactic path, but has delivered performance and code compatibility without peer.
What goes around comes around.