# User-defined types: structs, sums, and expectations ## Structs are product types In C++ a `struct` groups a fixed set of named fields. The compiler automatically provides a default constructor, a copy constructor, a move constructor, and a trivial destructor when the fields themselves support those operations. This mirrors the mathematical notion of a *product*: a value of the struct type contains one value of each field. ```cpp struct point { double x; double y; }; ``` The declaration above yields a type that can be constructed with brace initialisation: `point{1.0, 2.0}`. No user-written constructor is required, which satisfies the Core Guidelines recommendation to prefer aggregates (C.20). The fields are public by default. The type behaves like a plain data carrier, unlike the historic C `struct`, which cannot contain member functions or `const` qualifiers. Member functions can be added without sacrificing the aggregate property. A read-only member function is marked `const` so the compiler forbids it from modifying the object (C.2). The `point` example below adds `double distance(const point&) const`, which computes the Euclidean distance without changing `*this` and can therefore be called on a `const point`. An aggregate also supports designated initialisers. The syntax `point{.x = 1.0, .y = 2.0}` names each field explicitly. The compiler checks the order and the names, so a typo in a field name fails to compile. Designated initialisers make the intent of each value clear at the call site. They also survive a change in field order without silently swapping values. This form is the clearest way to build a small data carrier. The `point` type with its distance function is a complete example. The test verifies that the distance between two points is correct. ```cpp {{#include ../../examples/ch03/ch03_point.cpp}} ``` ## Invariants and the small private we allow A struct needs to enforce a relationship between its fields: an *invariant*. The book avoids class-based object orientation, yet a narrow use of `private` together with a public accessor is acceptable when the invariant cannot be expressed by the type system alone. For example, a normalized 3-D vector must always have length 1: ```cpp struct vec3 { private: double x, y, z; vec3(double a, double b, double c) : x(a), y(b), z(c) {} public: static vec3 make(double a, double b, double c) { double len = std::hypot(a, b, c); return vec3{a / len, b / len, c / len}; } double length() const { return std::hypot(x, y, z); } }; ``` The `private` section prevents accidental mutation that can break the invariant, while the static factory `make` guarantees a correctly normalised instance. This follows Core Guidelines C.21 to keep data encapsulation minimal and prefer plain functions over heavy OO machinery. The invariant, that a `vec3` constructed via `make` has length 1, is enforced by the factory. Direct use of the private constructor violates the contract, and the factory also checks for a zero‑length input and rejects it, avoiding a NaN result. Because the type system cannot express this invariant, the responsibility rests with the factory and disciplined callers. This trades a small runtime check for the complexity of a large class hierarchy. ## Defaulted comparison and the spaceship C++20 introduced the three-way comparison operator `<=>`, commonly called the *spaceship*. When a struct's fields already support equality and ordering, the compiler can generate all six relational operators automatically: ```cpp struct point { double x; double y; auto operator<=>(const point&) const = default; }; ``` Before C++20 each relational operator had to be written manually, a source of boilerplate and possible inconsistencies. The defaulted spaceship satisfies the Core Guidelines rule that the compiler must generate "obvious" functions (C.10, C.87). The generated operators perform a lexicographic comparison of the fields in declaration order, mirroring the behaviour of `std::tie`. The spaceship is the last piece the `point` type needs. With it, the type supports equality, ordering, and structured bindings, all without a hand-written operator. The compiler generates the comparisons from the fields, and the fields are the data. This is the Rule of Zero applied to comparisons: the type declares its intent (`= default`), and the compiler does the work. Structured bindings let a caller unpack a `point` into its fields in one statement. The form `auto [px, py] = p` binds `px` to `p.x` and `py` to `p.y`. The binding respects the declaration order of the fields, which matches the order that the spaceship compares. So the ordering of the fields has two consequences: it fixes the order of comparison and the order of the bindings. A reader who knows the field order can predict both. This consistency is why the book keeps field order stable across the type. The spaceship also reports the strength of the comparison. The defaulted operator returns a comparison category, and the compiler derives it from the field types. For a `point` of two `double` fields the category is `std::partial_ordering`, because floating-point values do not always compare as equal to themselves. The caller rarely names this category directly, yet it governs how the generated operators behave. This detail matters when a struct mixes fields of different comparison strength. ## `std::variant` as a sum type A *sum type* represents a value that is exactly one of several alternatives. In C++ the standard library provides `std::variant` for this purpose. It stores a discriminated union together with a runtime tag, guaranteeing safe access. The expression-tree example below demonstrates a binary addition tree built from numbers and nested operations: ```cpp {{#include ../../examples/ch03/ch03_exprtree.cpp}} ``` `std::visit` dispatches to the appropriate overload based on the active alternative. The helper `Visitor` aggregates the lambdas (a pattern often called *overloaded*) and makes the code concise. Compared with a traditional C `union`, `std::variant` carries a tag, eliminating the undefined behaviour that arises from reading the wrong member. Rust's `enum` offers a similar safety guarantee. The C++ version fits naturally into the existing type system without requiring a separate language construct. The expression tree is a Prolog term in C++ clothing. A `Node` is either a `Number` (a leaf) or a `BinaryOp` (a compound term with two subterms). The `eval` function is the interpreter: it walks the term and reduces it to a value. The `visit` call is the case dispatch, and the `Visitor` struct is the set of clauses, one per alternative. This is the pattern the book returns to in chapter 22, where a compile-time SQL parser builds a similar term and evaluates it at translation time. The full expression-tree example is a complete program. The test verifies that the tree evaluates to the correct value. ```cpp {{#include ../../examples/ch03/ch03_exprtree.cpp}} ``` ## `std::optional` for the maybe A function that can return a value or nothing uses `std::optional`. An optional either holds a `T` or is empty. It replaces the raw-pointer-returns-null idiom, which a caller can forget to check. The `value()` accessor throws `std::bad_optional_access` if the object is empty, and `operator*` is undefined for an empty optional, so the type makes the empty state explicit in the API. This pattern aligns with the Core Guidelines principle that error-prone pointer use must be avoided (F.4). An optional carries no information about why the value is absent. It answers the question "is there a value?" and nothing more. When the caller needs to know why the operation failed, `std::expected` is the right type, because it carries an error description alongside the absence. The choice between `optional` and `expected` is a question of what the caller must know. Use `optional` when the absence is a normal state, not an error. A map lookup that finds no key is a good fit, because the caller can proceed without the value. Use `expected` when the absence is a failure that the caller must handle or report. A file read that fails needs a reason, so the caller can log it or retry. The two types share the same shape, yet they carry different meaning. The book states the rule plainly: absence without a reason is `optional`, absence with a reason is `expected`. ## `std::expected` for fallible computations When a computation can fail with a recoverable error, `std::expected` conveys either a successful result of type `T` or an error description of type `E`. The parse-integer example returns an `int` on success or a `parse_error` struct describing the position of the first non-digit character. ```cpp #include struct parse_error { int position; std::string_view message; }; std::expected parse_int(std::string_view sv); ``` The caller inspects the returned object with `if (result)` and branches on success or failure. This approach is preferable to exceptions for anticipated failure such as malformed user input, because the control flow is explicit and does not incur the cost of stack unwinding. It also improves on `std::optional` by providing diagnostic information: the error type can carry a message, an error code, or any richer context the application needs. Chapter 9 expands on the trade-offs between exceptions, `expected`, and `optional`. The parse-integer example is a complete program. The test verifies that a valid input produces the correct integer and an invalid input produces the error message. The `expected` type also supports composition. A caller can chain operations so that a failure stops the chain early. The member function `and_then` applies a follow-up function only when the object holds a value. The member function `or_else` supplies a fallback when the object holds an error. These operations keep the control flow in the value domain instead of in a set of nested checks. The result reads like a pipeline of steps, and the error path stays visible in the type. This is the same spirit as the `visit` dispatch in the expression tree: the shape of the type drives the flow of the code. The error type `E` is a full type, not a fixed string. A program can define an error that carries a code and a message, or a nested error from a lower layer. The caller can inspect the error and decide how to recover. This flexibility is what separates `expected` from a bare `bool` return. A `bool` tells the caller that something failed, while an `expected` tells the caller what failed and where. The extra information is the reason the book reaches for `expected` over a status flag. ```cpp {{#include ../../examples/ch03/ch03_parse_int.cpp}} ``` ## Try this Extend the `point` example from the product-type section by adding a defaulted three-way comparison (`operator<=>`). Create three `point` objects, store them in a `std::vector`, and call `std::sort`. State in one sentence which comparison the sort algorithm used.