The type system as a tool: const, and compile-time computation

Lesson 15 gave us two channels for errors that do happen at runtime — exceptions and value-based results — and the safety guarantees that make them survivable. This lesson asks the prior question: which errors need to happen at runtime at all? The one new idea is push errors left — use the type system and the compiler to convert what would have been a runtime bug into a compile error, a mistake the program physically cannot be built to contain. We turn three tools to that end: const as a machine-checked promise, distinct types that make illegal states unrepresentable, and constexpr to move whole computations from run time to compile time.

1 · The principle: push errors left

Imagine the life of a bug laid out left to right on a timeline: compile time → link time → unit test → integration test → staging → production → 3 a.m. page. The same logic error costs almost nothing on the far left and a fortune on the far right. Push errors left is the discipline of moving each class of bug as far toward compile time as the language allows, because a bug the compiler refuses to build is a bug that can never reach a user.

Most languages give you only a thin slice of the left end: a type mismatch, a missing argument. C++'s type system is unusually powerful at this — not because it is safe by default (it is not; Lesson 19), but because it lets you encode invariants into types so that violating them is a syntax-level impossibility. The three tools below are how you spend that power.

2 · const-correctness: a promise the compiler enforces

const means this cannot change through this name. It is not a hint to the optimizer and not a comment — it is a contract the compiler checks: write through a const name and the program does not compile. That single guarantee, applied consistently, is called const-correctness, and it is one of the cheapest invariants you can buy.

const int kMax = 100;        // a constant; reassigning it is a compile error
int n = 5;
const int& r = n;            // a const *reference* — a read-only alias to n
// r = 7;                    // ERROR: assignment of read-only reference 'r'
n = 7;                       // fine — n itself is not const; r just can't write it

A const reference (const T&) is the workhorse. Recall from Lesson 06 that passing a parameter by value copies it. Passing by const T& does two jobs at once: it avoids the copy (a reference is just an address under the hood, so a huge object is passed as a pointer-sized alias) and it promises the callee will not mutate the argument. The caller reads that promise in the function's signature and relies on it without seeing the body.

// Cheap AND safe: no copy of the (possibly huge) string, and a checked
// guarantee that count_words leaves the caller's text untouched.
std::size_t count_words(const std::string& text);

// By contrast, this copies the whole string on every call:
std::size_t count_words_slow(std::string text);

const member functions

From Lesson 09, a member function receives a hidden this pointer to the object it was called on. A const member function — marked with const after the parameter list — promises this call will not modify the object. Mechanically, it makes this a pointer-to-const, so any line that would mutate a data member fails to compile inside it.

class Account {
  long cents_ = 0;
public:
  long balance() const { return cents_; }   // const: a pure observer
  void deposit(long c) { cents_ += c; }      // non-const: a mutator
  // long bad() const { cents_ += 1; return cents_; }  // ERROR: assignment of
                                                       // member in const method
};

This is where const earns its keep through propagation. Once you have a const Account& — which you will, the moment you pass an account by const reference — the compiler will let you call only the const member functions on it. Call balance(): fine. Call deposit(): compile error, because a non-const method might modify the object you promised not to touch.

// We promise (via const&) not to change the account when printing it.
void print_statement(const Account& a) {
  std::cout << a.balance() << '\n';   // OK: balance() is const
  a.deposit(100);                     // ERROR: passing 'const Account' as
                                      // 'this' discards qualifiers
}

Two refinements. const T* (pointer to const data) versus T* const (a const pointer to mutable data) were drawn in Lesson 03 — read the declaration right-to-left: const int* is "pointer to const int," int* const is "const pointer to int." And mutable on a member exempts it from const (used for a cache or a mutex), an escape hatch you reach for rarely and deliberately.

3 · Make illegal states unrepresentable

The strongest form of pushing left is to choose types in which the wrong value cannot be written down at all. If a state is illegal, the best defense is a type that has no way to express it — then no validation code, no runtime check, and no test is needed, because the compiler rejects the typo.

enum class — a closed set of named values

A plain C enum is just an int in disguise: it implicitly converts to integers, leaks its names into the surrounding scope, and lets you compare a Color to a FileMode as if they were the same thing. A enum class (a scoped enumeration) fixes all three: its values are a distinct type, do not silently convert to int, and must be named through the enum (Color::Red).

enum class Color  { Red, Green, Blue };
enum class Status { Ok, Error };

Color c = Color::Red;
// int x = c;                 // ERROR: no implicit conversion to int
// if (c == Status::Ok) {}    // ERROR: comparing Color to Status — different types
if (c == Color::Red) { /* the only legal comparison — same type */ }

The payoff: a function taking a Color cannot be handed a raw 2, a Status, or a "blue" that was really a stale array index. The set of legal arguments is exactly the named members, enforced at the call site.

Strong (distinct) types — a Meters that is not a Seconds

The famous bug: a function expects a distance in meters and someone passes a duration in seconds. Both are double at runtime, so the compiler — seeing only double — is happy, and the rocket lands in the ocean. The fix is to give each quantity its own type that holds a double but is not interchangeable with one. This is a strong typedef: same representation, distinct identity.

struct Meters  { double value; };
struct Seconds { double value; };

// Define addition ONLY within a unit. There is no Meters+Seconds operator,
// so writing one is a compile error, not a wrong number.
Meters operator+(Meters a, Meters b) { return { a.value + b.value }; }

double speed(Meters distance, Seconds time) {
  return distance.value / time.value;          // m/s — explicit, intentional
}

int main() {
  Meters  d{100.0};
  Seconds t{9.58};
  auto v = speed(d, t);                         // OK
  // auto bad = d + t;                          // ERROR: no operator+(Meters, Seconds)
  // double w = speed(t, d);                    // ERROR: cannot convert Seconds to Meters
}

The general pattern: wrap the primitive in a one-field struct (or a small class) so the type system can tell two things apart that the machine cannot. UserId vs OrderId (both int), Celsius vs Fahrenheit, SanitizedHtml vs RawInput — anywhere a function takes two arguments of the same primitive type, transposing them is a bug a strong type makes unrepresentable.

4 · constexpr — move the work to compile time

The other half of "the compiler works for free" is constexpr: a marker that a value or function can be evaluated at compile time. If the inputs are known at compile time, the compiler runs the computation during the build and bakes the result — a literal — into the binary. The running program does no work; it just loads a number that is already there. This generalizes Lesson 12's "the compiler computes at build time" from types to values.

constexpr int factorial(int n) {            // *can* run at compile time
  return n <= 1 ? 1 : n * factorial(n - 1);
}

constexpr int f10 = factorial(10);          // computed during compilation
int arr[factorial(5)];                      // legal: 120 is a compile-time constant,
                                            // and array sizes MUST be one

; f10 = factorial(10), as compiled:
mov DWORD PTR [rbp-4], 3628800   ; the answer, precomputed — no call, no multiply

static_assert — a check the build must pass

static_assert(condition, "message") is an assertion evaluated at compile time. If the condition is false, the program does not build and the message is the error. It is the most direct "push left" tool: a precondition that fails the compiler instead of the program.

static_assert(factorial(5) == 120, "factorial is wrong");   // checked at build
static_assert(sizeof(void*) == 8, "this code assumes a 64-bit target");
static_assert(factorial(0) == 1,  "0! must be 1");
// If any condition were false, compilation stops here with the message.

A compile-time lookup table

Because a constexpr function can fill data, you can build whole tables at compile time. The table ends up as a block of literals in the binary — the program never computes it, it ships pre-filled.

#include <array>
constexpr std::array<int, 8> factorials() {
  std::array<int, 8> t{};
  int acc = 1;
  for (int i = 0; i < 8; ++i) { acc = (i == 0) ? 1 : acc * i; t[i] = acc; }
  return t;
}
constexpr auto kFact = factorials();        // 1,1,2,6,24,120,720,5040 — in the binary
static_assert(kFact[5] == 120);             // and verified during the build

5 · A taste of type traits and if constexpr

The compiler can also ask questions about types and branch on the answers, all at build time. The standard <type_traits> header is a library of compile-time predicates — std::is_integral_v<T>, std::is_pointer_v<T>, and so on — each a constexpr bool the template machinery (Lesson 12) evaluates while stamping out code for a given T.

if constexpr (C++17) is an if resolved at compile time: the branch not taken is not just skipped at runtime, it is discarded entirely — never compiled for that T. This lets one template do the right thing per type with zero runtime branching.

#include <type_traits>
template <typename T>
void describe(T x) {
  if constexpr (std::is_integral_v<T>) {
    std::cout << "integer: " << x << '\n';      // compiled only when T is integral
  } else {
    std::cout << "not an integer\n";            // compiled only otherwise
  }
}
// describe(42)   -> the integral branch is the ONLY code generated
// describe(3.14) -> the else branch is the only code generated

You can pair traits with static_assert to reject misuse with a readable message — static_assert(std::is_integral_v<T>, "T must be an integer type"); turns a cryptic deep-template error into a one-line explanation. (C++20's concepts, previewed in Lesson 12, are the modern, even cleaner way to state such a requirement on a template.)

6 · Common mistakes / failure modes

Checkpoint exercise

Where this points next

We have spent this movement making the compiler your strongest ally: it stamps out generic code (12), models containers and costs (13), composes algorithms (14), keeps exceptions safe (15), and now refuses to build code that violates the invariants you encoded in types. Lesson 17 leaves the comfort of a single thread and meets the one bug class the type system cannot push left on its own: the data race. When two threads touch the same memory and at least one writes, with no synchronization, the result is undefined — and no const, no strong type, catches it by itself. We will see why shared mutable state is the enemy, and how RAII (Lesson 05) returns to make locks leak-proof.

Interview prompts

• What does "push errors left" mean, and why is a compile error cheaper than a runtime one? (§1 — move each bug class toward compile time; a bug the compiler refuses to build can never ship, costs nothing at runtime, and is found instantly by everyone, versus a runtime bug that fires only on some executed path.)
• What two things does passing by const T& accomplish at once? (§2 — it avoids copying the argument since a reference is pointer-sized, and it makes a compiler-checked promise that the callee will not mutate the caller's object.)
• What does const after a member function's parameter list mean, and how does it propagate? (§2 — it makes this a pointer-to-const so the method can't modify the object; once you hold a const reference to an object you may call only its const members, so a stray mutation becomes a compile error.)
• Why prefer enum class over a plain enum? (§3 — scoped enums are a distinct type that doesn't implicitly convert to int and doesn't leak names into the scope, so comparing or passing the wrong enum is a compile error rather than a silent integer mix-up.)
• How does a strong type catch a Meters/Seconds mix-up, and what does it cost at runtime? (§3 — each unit is its own type wrapping the same primitive, so there is no conversion or cross-unit operator and the mix-up won't compile; at runtime the wrapper compiles away to the bare primitive — zero overhead.)
• Does constexpr guarantee compile-time evaluation? How do you prove it happened? (§4 — no; it means "can be evaluated at compile time" and falls back to a runtime call when inputs aren't constant. Force/confirm it by assigning to a constexpr variable, using it in a static_assert, marking it consteval, or checking the assembly for the baked-in literal.)
• What does if constexpr do that a normal if doesn't? (§5 — the not-taken branch is discarded at compile time and never compiled for that type, so a template can select per-type behavior with no runtime branch and without requiring the dead branch to be valid for every T.)