Designing Generic Functions

Imagine a generic function named sum() that adds up the elements of something. Its template parameters look like open slots that will accept any type at all. Yet the function clearly cannot work with just any type. It needs a collection it can walk through, and it needs a numeric type it can add with. Those expectations are never written into the parameter list, but the function depends on them completely.

The question to keep in mind as you read this article is simple: when a function is generic, where do its real limits live, if they are not written into its parameter list? The answer is in the concepts the function relies on.

Think of a concept as a job description rather than an employee. The job description says what a candidate must be able to do. Many different people can fit the same description, and the description is useful precisely because it can be checked against any candidate. In generic programming, a concept describes what a template argument must be able to do, and many different types can satisfy the same concept.

The source gives a set of familiar examples: integer, floating-point number, field, vector space, and container. The first two are ideas you already use in ordinary programming. The others come from mathematics and from the collections software is built around. Each one is a bundle of expectations rather than a single type. A container is not one specific class. It is any type that provides the behavior people expect of a container.

The sum() example makes the hidden concepts concrete. The function has two kinds of need. First, it needs something it can iterate over, a collection whose elements it can walk through one at a time. That requirement is the container concept. Second, it needs a value type it can add with, and that requirement is the number concept. Neither requirement appears as a name in the template parameter list. Each one sits behind a template argument and is only visible when you look at what the body does.

You can recover the hidden concept of any generic function by tracing what it does with each type parameter. The source offers a practical habit: for each type parameter, ask what the function does with values of that type. The answers reveal the concept, because the concept is the summary of those expected uses.

A template parameter list states what the caller may pass in, but it does not state what the function body depends on. A signature with unconstrained type names promises very little. The full concept includes every requirement the body actually relies on, including requirements the signature leaves out. The gap between the two is where the hidden expectations live.

Read the two columns as a contract question. The left column is what the signature says to the caller. The right column is what the body quietly needs. A caller who reads only the signature will believe that any type is acceptable, and that belief is wrong for this function.

A natural question follows from the sum() example: if the function depends on these requirements, why not write them into the code? The source answers directly. Concepts cannot be expressed directly in C++11. The language lets the programmer pass types into a template, but it does not provide a direct way to declare that a template argument must be a container or must be a number.

This is why the programmer must understand the requirements. Since the language cannot state them, the burden falls on the author to work out the concept, name it, and make it clear to anyone who calls the function.

The source makes a claim worth pausing on: good, useful concepts are fundamental, and they are discovered more than they are designed. A programmer rarely invents a concept from nothing. The concept is already present in the field of application, and the work is to notice it, state it clearly, and write it down with enough precision for generic code to rely on it.

The source also notes that identifying and formalizing a concept to the degree needed for effective generic programming can be a real challenge. The phrase to the degree necessary matters. A concept does not have to capture everything about a type. It has to capture enough of the requirements that generic code can be written correctly against it.