This is the second chapter of the PragmatiC++ draft — a book on pragmatic C++ that still makes sense a year later. The chapter source is open on GitHub.
About four years ago, at the seam between two projects — when the old one was just being supported and the new one was still in preproduction and pitches of varying completeness (planning and attempts to sell the concept and ideas to uninterested investors) — my team back then somehow ended up with free time, and somewhere between teaching newcomers the wisdom of the custom engine, attempts to switch to the C++20 standard and the backlog retrospective, on a sunny September morning the idea was born to run studio discussions in the style of a C++ theory podcast, to figure out which features were implemented in the engine, what competencies the new hires had, and to generally refresh the theory a bit. So a mini-course of in-house lectures was born, given by different people with different but real experience of applying it, later settling into the local wiki as a set of articles, best practices or just notes with a gamedev focus. So that all this good stuff wouldn't go to waste — since quite a lot of man-hours went into it — I decided to polish these notes and post them in a readable form (there won't be video, unfortunately, because of NDA and all sorts of project spoilers and the local kitchen of development, and no one would listen to those dozens of hours of chatter anyway), but the principles of the language and its features are something copyright has no power over, so in this form it seems okay. Unfortunately, we'll start not with generic programming but with the second podcast about overloads, because the first recordings turned out to be corrupted and restoring them will take time. So, overloading in C++, not the way it's taught at university and given in books...
Let's talk about overloads and generic programming, but let's start not with syntax and not with templates, the way it's presented in most textbooks and technical literature, but with the idea. In C++, function and method overloading is often perceived as a convenience or a way to "nicely name different things the same way," but in fact it's a far more powerful tool whose skillful use lets you build universal interfaces. Interfaces that can be extended to new data types in such a way that they remain clear and safe.
To understand this, you need to recall what generic programming and its particular application as overloads are actually founded on. The founders of the STL formulated the key idea of the standard library as simply as possible: first you need to correctly compose (come up with) the algorithm, and only then figure out which types it works for. This phrase is often heard at conferences and in the books of smart people, but in practice it's constantly violated. Violated not because it's hard to do, but because it's very easy to start with types, classes, hierarchies and other base things familiar to a programmer, and only then try to "stretch" an algorithm over them. Generic programming itself offers the opposite path, and if you look at the standard library's algorithms, they're as generic as possible, and in most cases will work both for plain integers and for a complex class with overloaded operators.
Starting from the algorithm's task, you should always abstract away from concrete data types and ask yourself not "what kind of object is this" but "what operations on it are needed." Do we need to be able to multiply values, compare them, copy them, create a neutral element? The answers to these questions will naturally reveal the requirements on the types, which won't be conjured out of thin air — and to speed up (a physical quantity) of some entity, floats won't suddenly appear (yes, it fits syntactically, but a float wasn't even close semantically); rather, they become a consequence of the algorithm.
The classic textbook example of overloading
What most textbooks write:
// "Function overloading lets you use one name
// for functions with different parameter types"
// Function to add two integers
int add(int a, int b) {
return a + b;
}
// Function to add two floating-point numbers
double add(double a, double b) {
return a + b;
}
// Function to add three integers
int add(int a, int b, int c) {
return a + b + c;
}
// Function to concatenate strings
std::string add(const std::string& a, const std::string& b) {
return a + b;
}"The compiler will choose the right function based on the types and number of arguments. This is called overload resolution."
// Pavlovskaya
// Area of a circle
double area(double radius) {
return 3.14159 * radius * radius;
}
// Area of a rectangle
double area(double width, double height) {
return width * height;
}
// Area of a triangle
double area(double base, double height, bool is_triangle) {
return 0.5 * base * height;
}
int main() {
std::cout << area(5.0) << "\n"; // circle
std::cout << area(4.0, 6.0) << "\n"; // rectangle
std::cout << area(3.0, 4.0, true) << "\n"; // triangle
}// Stroustrup
// Complex numbers
class Complex {
double re, im;
public:
// Constructor from two numbers
Complex(double r, double i) : re(r), im(i) {}
// Constructor from one number (imaginary part = 0)
Complex(double r) : re(r), im(0) {}
// Default constructor
Complex() : re(0), im(0) {}
void print() const {
std::cout << re << " + " << im << "i\n";
}
};The examples above are syntactic sugar, and by thinking within the frame of types — "we have int, double, string, let's write a function for each" — the general solution is missed. The invented set of overloads becomes a way to call similar things the same way, so the programmer doesn't have to remember add_int(), add_double(), add_string(). But this is a superficial understanding that doesn't take the programmer beyond procedural thinking — it's not the generic programming you see in std when you dig into the algorithms. It's just syntactic sugar masking a set of separate functions under a single name.
Generalizing the algorithm
In "Notes on Programming" Stepanov writes: "Structured Programming School: Dijkstra, Wirth, Hoare, Dahl. By 1975 I became a fanatical disciple. I read every book and paper authored by the giants. I was, however, saddened by the fact that I could not follow their advice. I had to write my code in assembly language and had to use goto statement. I was so ashamed. And then in the beginning of 1976 I had my first revelation: the ideas of the Structured Programming had nothing to do with the language." (Notes on Programming).
I read both this Stepanov book and Dijkstra's books, and I prefer another approach he borrowed from Gries/Dijkstra (David Gries/Edsger Dijkstra) — also an almost textbook example — raising a number to a power, computing x to the power of n. The very first solution that comes to mind looks trivial: we set up an accumulator variable and multiply it by x n times in a loop. This solution is easy to explain, easy to write and easy to verify, and it's often proposed at interviews. Once the main question wasn't "how to do it" (practically everyone can write the solution), but can it be done faster?
template <typename T>
T pow_naive(T x, unsigned n) {
T result = T{1};
for (unsigned i = 0; i < n; ++i)
result = result * x;
return result;
}It turns out it can, and significantly. There's an algorithm called exponentiation by squaring. It relies on the binary representation of the exponent and lets you solve the problem in logarithmic time. Instead of doing n multiplications, each time we halve the exponent and square the base. If the current exponent is odd, we additionally multiply the result by the current value of the base.
template <typename T>
T pow_fast(T x, unsigned n) {
T result = T{1};
while (n > 0) {
if (n & 1)
result = result * x;
x = x * x;
n >>= 1;
}
return result;
}Intuitively this algorithm can be understood like this: any integer can be represented in binary, which means any power can be decomposed into a product of powers of two. For example, x to the 13th is x to the 8th times x to the 4th times x to the 1st. The algorithm sequentially "runs" through the bits of the exponent, starting from the least significant, and each time decides whether the current base participates in the final result.
x^13 = x * x * x * x * x * x * x * x * x * x * x * x * x
13₁₀ = 1101₂ = 8 + 4 + 1
x^13 = x^8 * x^4 * x^1
x^1 = x (0 multiplications)
x^2 = x^1 * x^1 = x² (1 multiplication)
x^4 = x^2 * x^2 = x⁴ (2 multiplications)
x^8 = x^4 * x^4 = x⁸ (3 multiplications)
Bits of 13: 1 1 0 1
↓ ↓ ↓ ↓
x^8 x^4 _ x^1
R = x^8 * x^4 * _ * x^1It's important to note not so much the algorithm itself as what it actually requires of the data type. The algorithm doesn't care whether x is an integer, a real number, a very large or small integer (int6_t/int128_t), a matrix or something else. All it needs is for a multiplication operation to exist, for there to be a neutral element, and for values to be copyable. Everything else is implementation details.
And here we arrive at the connection with overloads and generic programming. The algorithm is one and the same, described in abstract terms, while the concrete multiplication operation is chosen depending on the type. For int it's one multiplication, for double another, and for a matrix a third — and it's precisely through overloads and generic interfaces that the language lets you link one algorithm with many concrete implementations.
And it turns out that overloads become not just a way to avoid different function names, but turn into a mechanism that lets you express the idea: "one and the same algorithm, applicable to different types, if they satisfy certain requirements." Now overloading is an integral part of generic programming rather than its incidental "convenient" effect.
If you keep this thought in mind, designing interfaces and algorithms starts to look different, when we begin to think not about classes and hierarchies but about the meaning of operations and about which properties of types make an algorithm correct and efficient. That's exactly where truly beautiful and generic code begins.
Generalizing the conditions
Now that we have the algorithm itself, it's logical to ask the next question: how do we make it generic? How do we turn a solution for integers into an algorithm that works not only with unsigned but with other data types too?
The first impulse is usually very straightforward — you want to just replace the concrete type with a template parameter, a conditional T, and consider the task solved. Formally the code does become templated, but almost immediately it becomes clear that this is only a superficial generalization, not a real one.
Take, for example, a check of the form x < 0. It only makes sense for signed numeric types. If T is an unsigned type, this expression is meaningless. If T is a matrix, a vector or a user-defined type, such an operation may not exist at all. This is the first signal that the algorithm in its current form is in fact rigidly tied to concrete data types.
The neutral-element problem
Another, even more fundamental problem is connected with initializing the result. And while in the simplest version of the algorithm we start with one — which for integers and reals looks natural — the moment you go beyond scalar arithmetic, the question stops being trivial. For matrices, is "one" the identity matrix? And for complex numbers? And for user-defined types? The algorithm itself shouldn't and can't know what value plays the role of the neutral element for multiplication.
template <typename T>
T power(T x, unsigned n) {
if (x < 0) // problem, a partial solution
x = -x;
T result = 1; // problem, one doesn't suit everyone
while (n--)
result *= x;
return result;
}You can try to solve this problem by introducing some global function like identity(T) that returns the neutral element for type T, and at first glance it looks elegant and will even work (for a while), but in reality such a solution is too rigid. It imposes a global convention that may not exist, and requires every type to support a non-standard interface, which immediately reduces the algorithm's universality and makes it harder to integrate into existing code.
A much more natural and "standard STL-ish" approach is not to try to guess the neutral element inside the algorithm but to pass the initial accumulator value from outside. In this case the algorithm receives already correctly initialized state and simply does its work, without making assumptions about the data type and without implementing logic not directly related to computing the power. Now you understand why STL algorithms often require an initial element?
This style fully matches the philosophy of the C++ standard library. Algorithms in the STL are a kind of "clean rooms" that don't validate input data for correctness, don't create objects and don't make architectural decisions for the programmer. Their job is to correctly and efficiently perform a given sequence of operations, while the responsibility for preparing arguments, choosing initial values and observing preconditions lies with you and me and the external logic that calls the algorithm.
template <typename T>
T power(T base, unsigned n, T result) {
while (n--)
result *= base;
return result;
}Only this way do we get a truly generic algorithm that works with any types for which the necessary operations are defined, while keeping it simple, transparent and easy to verify. That's exactly how generalization and overloads start working not as a language trick with same-named functions, but as a design tool.
Generalizing the overloads
But in practice we almost never deal with a single "universal" function; instead we work with a set of functions united by one property (not necessarily the name). It's not one abstract power/pow, but a whole set of overloaded functions, constructors, operators and methods that exist under one name and together form a single, flexible interface. The programmer sees one name and one concept, while the compiler sees dozens of different implementations you may not even be aware of, and picks the one most suitable for the concrete type. It's precisely this combination of overloads that lets you write code that is at once convenient, expressive and without loss of performance.
template <typename T, typename Op>
T power(T base, unsigned n, T result, Op op) {
while (n--)
result = op(result, base);
return result;
}Here it's worth stressing that the zoo of overloads doesn't compete with generic programming but complements it. The templated algorithm sets the general form of the solution, while the overloaded operations and helper functions provide optimal behavior for concrete cases — i.e. we go not from data types to the algorithm, but from the algorithm's capabilities to the permitted data types, and as a result we get a generic interface that seems simple but internally accounts for the differences between types.
To see this on an example from the standard library itself, you don't need to dig into the implementation of pow; you can take a simple comparison operator for strings. At first glance the task looks elementary: we have std::string, we have the == operator, and we could write it in the most straightforward form — take two strings by reference and compare them via compare — and such code will be correct and clear for most programs and developers, but it contains the "single window" problem, or the "insufficient overload set" problem. Although this is more a descriptive expression than an established term — the "single window" wording is intuitively clear in the Russian community and accurately describes the situation, but in the C++ community it's discussed as part of the broader topic of designing overload sets.
The problems begin as soon as we step outside the ideal case, because in real code strings are compared with anything, and very rarely specifically with strings. Very often one of the operands will be a string literal, on the left as well as the right, like "hello", or a const char* pointer obtained from a C interface; and if we have only one version of the operator taking two std::string, the compiler will be forced to perform an implicit conversion. The literal will turn into a temporary string object for which memory must be allocated, the data copied, and then almost immediately all of it destroyed.
From a semantics standpoint the program remains correct in all cases, but from an efficiency standpoint we get extra work — and the most unpleasant part is that this inefficiency is hidden from the developer by a "convenient" call. The call really does look harmless, even if under the hood dynamic memory allocation happens. And here the power of a set of overloads shows itself: instead of one universal operator, the standard library provides several variants — comparing a string with a string, a string with a C-string, a C-string with a string. They all logically mean the same thing — an equality check — but are implemented so as to avoid unnecessary conversions and temporary objects in each concrete case.
string == string
const char* == string
string == const char*For the developer the interface stays the same: we just write a == "hello" and think about implementation details only in complex cases, or when we get a compile error, or see performance problems. For the compiler the set of overloads turns into a set of clearly stated rules from which it picks the most appropriate. This is exactly the well-designed interface the STL represents: a single name, a single meaning, but different implementations, each optimal for its set of types.
From this simple example, which you most likely use every day, an important rule of good design follows — overloads shouldn't change the meaning of the operation, only refine it for different forms of input data. If different overloads do "different things," the interface becomes confusing and treacherous, and the conditions of use slippery. That's exactly how the standard library achieves its balance of universality and convenience, without the need to write specialized code by hand.
Good overloads
Real life of course gives us non-ideal sets of programmatic interfaces, and almost inevitably the question arises — "how well designed are they even?" Formally the code may be correct, compile and even run fast, while still being inconvenient and treacherous to use. The problem is that overloads interact directly with the type system and the call-resolution rules in C++, and that's one of the hardest parts of the language, and with each new standard it doesn't get easier, rather the opposite.
void log(const char* msg);
void log(const std::string& msg);
void log(const std::string_view& msg);
log("hello"); // which overload?
std::string s = "world";
log(s); // here it's obvious
log(s.substr(0, 3)); // and here?Sometimes it's customary to joke that a good overload set is the one you wrote yourself (because you understand what you did and how it works). And a bad one is the one someone else wrote, because you have to figure out why the compiler chose this particular overload and not another. As usual, in every joke there's a grain of a joke, but in practice there are quite concrete quality criteria after all.
These criteria were well formulated by Tim Sweeney (yes, the author of that very Unreal — and before him also Titus Winters, but more generally, and I learned about Titus much later than about Sweeney) many years ago, and the fruits of his approach we now see in the development of the Unreal Engine; and what makes it valuable is that it comes not from abstract "beauty" but from real experience supporting and developing one of the most complex systems in game development.
The first and perhaps most important principle goes like this: the developer shouldn't have to solve the overload puzzle in their head. If, to call a function correctly, you need to know well all the subtleties of the overload-selection rules in the engine, understand template priorities, implicit conversions and the pitfalls of references and values, this almost always means a bad interface design. A good overload set works intuitively — I look at the function name or the code and immediately understand what will happen and how, without looking into the documentation.
void log(std::string_view msg) {
write_to_log(msg);
}
log("hello");
log(s);
log(s.substr(0, 3));The second principle is closely related to the first — all overloads belonging to one set should have a single clear purpose that can be expressed in one short phrase. For example: "compare two strings for equality" or "raise a value to a power," as in the examples above. If, when explaining each overload, you have to make caveats, write comments or dance with a tambourine, then in fact different operations are hiding under one name, and such an interface starts to mislead, losing its integrity.
The third principle was developed much later and consists in the fact that each overload should do roughly the same thing. The behavior should be roughly identical regardless of which version the compiler chose. Differences between overloads are permissible only at the level of performance, forms of data representation or ways of passing arguments, but not at the level of meaning. If one overload logically does one thing and another something noticeably different, this is almost guaranteed to lead to bugs and unexpected effects.
// the interface-spread problem
void open(File& f);
void open(const char* path);
void open(const char* path, bool create_if_missing);It's important to note that the first two principles actually follow from the third, or you could say the third is their generalization. If all overloads really do the same thing, the user doesn't have to puzzle out which one to pick, and their purpose is easily formulated in one phrase. But as soon as this unity is broken, the interface starts to "spread," and overloads turn from a tool of expressiveness into a source of complexity.
Bad overloads
To better feel the boundary between good and bad design, it's useful to consider a deliberately unfortunate example of an overload set. Imagine a function with one name, say resolve, that has two overloads. In one case it takes an integer and, for example, normalizes it, bringing it into some allowed range, and in the other case the same function with the same name takes a string and… parses it as a file path, checking the existence of that file in the file system.
Formally, from the language's standpoint, syntactically everything looks legal. This really is one overload set, the compiler will without problems pick the right version depending on the argument type, but from the standpoint of usage semantics the problems begin. Under one name two operations are hiding that have almost nothing in common, solve different tasks, work with different application domains and require a different context.
Try reading such code without comments: the call resolve(x) can still somehow be interpreted if you know the type of x. But on its own it says nothing about the author's intent, and the call resolve("data/config.json") looks even worse: it's unclear what exactly will happen — parsing a string, checking a file, loading data or something else. To understand the behavior, you have to either dig into the documentation or know all the overloads by heart.
int resolve(int x)
{
// normalize, pick the nearest allowed value, etc.
if (x < 0)
return 0;
if (x > 100)
return 100;
return x;
}
int resolve(const std::string& path)
{
// check existence and read the configuration
std::ifstream file(path);
if (!file)
return -1;
int value;
file >> value;
ret
}At this point the comment on the function ceases to be an explanation and turns into part of the code, and that's a sure sign that under one name two different pieces of functionality are actually hidden, which were simply given the same name for some reason.
// here we have the secret blueprints
auto a = resolve(x);
// and here we were wrapping fish
auto b = resolve("data/config.json");"Broken" overload sets are dangerous because they mask a problem of visibility and responsibility. And even if the code compiles, looks tidy and passes review, that doesn't mean you won't have to look at each overload separately when changing it. As soon as the interface starts being used in a larger scope or falls into the hands of another developer, it becomes a source of problems.
A good rule here is simple: if you can replace an overload with a different name and the code doesn't get worse, then the overload was a bad idea. You should overload only when one concept stands behind one name. It's clear that names are "few" and people prefer to economize on them at the expense of meaning, but such economy stops being expressive and starts only to mislead.
Another bad example
If you look critically at the not-so-old changes to the standard library, you can find examples where the principles of good overload-set design are violated. And one of the most telling cases is std::filesystem — this has been said more than once in committee discussions.
std::filesystem is often cited as an example of a "modern" and convenient API for working with the file system, and in terms of the capabilities it brings it's indeed rich and a big step on the path of the language's development, but if you look specifically at the implemented overload design, it's far from the standard the algorithms were.
The problem starts with the central data type std::filesystem::path. This type is conceived as a universal representation of a path, and a huge number of overloaded functions are built around it — i.e. it wasn't the algorithm that was the starting point, but established usage practice and the data type. So almost every operation has several versions: with path, with const char*, with std::string, sometimes with an extra std::error_code, sometimes without it. Formally this should all look like a convenience for the user, but in practice it turns into a complex and ambiguous labyrinth of decisions, where an inexperienced developer usually picks the first suitable solution — note, not the correct one, but the suitable one. I think everyone has seen that funny video; it's sad, but it's exactly what describes how most developers work with std::filesystem.
For example, the function exists: in one case it takes a path and may throw an exception, in another it takes a path and a std::error_code and doesn't throw exceptions. Semantically these are already two different contracts: one version works through exceptions, the other through error codes, while the function name is one and the same. And looking at the call exists(p), you don't see in the code which error-handling model is used until you look at the signature or documentation.
std::filesystem::exists("data/config.json");
// Throws exceptions
bool exists(const std::filesystem::path& p);
// Doesn't throw, returns the error via error_code
bool exists(const std::filesystem::path& p, std::error_code& ec) noexcept;The situation gets even worse when implicit conversions come into play — std::filesystem::path is implicitly constructed from a string. As a result, a call that at first glance looks harmless actually involves creating a temporary path object, allocations, an encoding conversion and, again, a choice among several overloads. To know exactly which version will be called and what side effects it will entail, you need to know well all the overloads and their resolution rules.
A separate problem is overloads that combine operations with different meanings under very general names like status, symlink_status, exists, is_regular_file, is_directory — they look like variations of one idea, but in fact differ in behavior, especially in the presence of symbolic links and errors. And the developer is forced to constantly remember which function follows links, which doesn't, and how each of them reacts to an inaccessible path. Formally it turns out that this isn't one overload but a separate family of APIs that was laid into the linear space of the standard library on a par with the algorithms. But while the algorithms explicitly say what they do inside (I do what you see), here the whole cognitive load (read the docs before using) is shifted onto the developer.
From the standpoint of the principles described above, several points are violated here at once. We're explicitly forced to "solve the overload puzzle" in our heads, and to use std::filesystem correctly (so as not to be the person in the video above) you need to remember not only the purpose of the functions but also the differences between their versions related to errors, exceptions and implicit conversions. The purpose of the functions couldn't be expressed in one short name, because different behavior models hide under one name. And finally, the overloads don't do quite the same thing — the differences aren't limited to performance, they touch the very meaning of the call.
This doesn't mean that std::filesystem is "bad" or shouldn't be used. This part of the standard library solves a big and complex task, and the chosen API merely reflects the explicit compromises that were made during standardization. From the standpoint of good design, the local overload set is more a cautionary example than a model to imitate. The code becomes less self-documenting, and understanding what's going on requires knowledge of the library's details — and that's exactly why, when designing your own interfaces, it's useful to remember this example, where even the standard library isn't insured against debatable decisions; but there are of course weighty reasons why it was done this way and why they went for exactly this kind of interface.
How to do it better
If we continue the conversation about good overload sets, it's useful to look at situations where overloading really works "as intended" and strengthens the interface rather than complicating it. Such examples are usually united by one important trait: all the overloads serve one and the same idea, just adapted to different forms of input data or different usage scenarios.
Let's start with the simplest and perhaps most common case: overloads for related types. Here we can return to working with strings in C++; if you look at your code, you'll see that the representation of strings comes down to two types (std::string and const char*). This looks natural to those who use the language, because both types represent a string, just in a different form, and it's a historical legacy that became a rule.
A good "historical" practice is to make one of these overloads the base one and the other a thin wrapper. One takes (let's call it the thin wrapper) std::string, the other (the base one) calls the const char* variant. As a result the behavior always stays unified, all the logic is concentrated in one place, and you avoid creating temporary objects and extra memory allocations, without complicating the convenient interface and the implementation.
Another common and quite justified technique is adding overloads by the number of arguments. Imagine a function concat that assembles a string from several fragments. From the user's standpoint it's convenient to be able to pass one fragment, two or three, without thinking about containers, an argument array or formatting. Calls like concat("Hello"), concat("Hello", world) or concat("Hello", world, '!') look natural and read easily.
auto s1 = concat("Hello");
auto s2 = concat("Hello, ", world);
auto s3 = concat("Hello, ", world, "!");What matters is that in all these cases the goal stays one and the same: build a string. The difference is only in the amount of input data, and the overloads don't change the meaning of the operation, they only make the interface more flexible and convenient. We don't need to know the implementation details, and with high confidence the compiler will simply pick the call form that best fits the current task.
Another well-known example is std::vector::push_back, where overloading is used no longer for convenience but for performance. There's a version taking const T&, intended for copying an already-existing object, and a version taking T&&, which lets you efficiently move temporary objects or the results of std::move. From the programmer's standpoint both functions do the same thing — namely add an element to the end of the vector — but from the implementation standpoint they differ fundamentally in the cost of the operations.
T a;
vec.push_back(a); // copy
vec.push_back(T{}); // move
vec.push_back(std::move(a)); // explicit moveThat's exactly where the power of such an overload set lies: the semantics stay unified, the behavior predictable, and the differences show up only in efficiency, and we don't have to think about which overload exists, letting the compiler choose the optimal one.
Conclusion
If we generalize these examples, the main principle when working with overloads becomes clear — they should solve one and the same task, but for different forms of input data or different situations. They shouldn't change the meaning of the operation and, even more so, shouldn't mislead the developer. In C++ overloading is a powerful tool for creating convenient and performant interfaces, but only on the condition that the unity of semantics and common sense is preserved. As you've probably noticed, a large number of overloads makes the interface flexible, but at the same time increases the risk of confusion and implicit errors. To keep an overload set predictable and safe, it's important to explicitly state for which types this or that overload is permitted.
Historically in C++ techniques like SFINAE and enable_if were used for this; they worked, but the code quickly became hard to read and maintain. With the arrival of concepts and requires the situation improved enormously, and type constraints became part of the interface — readable and expressive — while overload management became explicit and controllable. It's exactly this that today lets us build generic APIs that remain powerful while staying understandable to a human, not just the compiler. And that will be the subject of the next chapter...