A units library must preserve meaning at numeric boundaries

A function parameter of type double cannot say whether its value is a distance, a speed, or an angle. Giving that parameter a unit-aware type helps, but the safety problem continues when the program converts units or extracts a raw number for an older API. October's physical-quantities papers examine those boundaries directly.

P2981R0, dated October 15, focuses on safety. Its companion P2980R0 describes motivation, scope, and a standardization plan. The papers draw on existing units-library work, including mp-units, and explicitly warn that their examples do not establish the eventual standard interface.

Templates make this a particularly interesting use of C++ for me. They can encode a domain distinction in the type system while leaving the stored representation simple. That is useful only if the interfaces preserve the distinction where values enter and leave the abstraction.

A number and its unit must enter together

P2981R0 discusses the danger of constructing quantities from bare numbers. Its example changes a container's duration type from milliseconds to microseconds while leaving an emplace_back call with the same raw integer. The source still compiles, but the value's intended meaning changes.

An explicit constructor does not prevent that particular mistake. Emplacement deliberately invokes construction, so a raw value can still acquire whatever unit the container's element type currently implies. The call site has not recorded the unit it meant.

The paper's proposed discipline requires both the number and unit during construction. Changing the destination representation then has to respect the supplied quantity. A unit conversion can occur, but it follows the meaning expressed at the call site.

This is a stronger interface than a comment naming the expected unit. The type system can check a conversion relationship. A comment can become inconsistent when another declaration changes, leaving the compiler no way to identify the disagreement.

Integral conversions can lose information

Automatic unit conversion needs a policy for the numeric representation. An integral number of smaller units may not be representable as an integral number of larger units. The paper uses meters and kilometers to demonstrate the potential truncation.

A conversion that silently produces zero can preserve the destination's type while losing the source's information. The units are dimensionally compatible, so dimensional checking alone does not address the problem. The representation and conversion direction matter too.

P2981R0 therefore argues against implicit truncating conversions. It describes named operations for deliberately forcing a conversion and alternatives using floating-point representation. The intent is to make information loss an explicit decision in the source.

My preference is for that decision to remain visible. A unit-aware type should not give the impression that every conversion is exact merely because both quantities measure length. It should distinguish compatible dimensions from a value-preserving representation change.

Extracting a raw number needs a destination unit

The paper also examines calls into legacy interfaces that take ordinary integers. A quantity can represent the intended duration correctly while storing its raw count in a unit different from what the callee expects.

Calling a bare count accessor then discards the unit at precisely the point where the boundary needs it. A later refactor of the stored unit can change the number passed to the old interface without changing the call site.

The proposed library style requests a numerical value in a named unit. That makes conversion part of extraction. The caller expresses the unit required by the destination interface instead of relying on the quantity's current storage convention.

Reference extraction has an additional restriction. A reference cannot stand for a newly converted temporary value as though it were the stored representation. The paper describes allowing a numerical reference only for a compatible stored magnitude and an lvalue source, reducing dangling opportunities.

Equal dimensions do not imply equal quantity kinds

P2981R0 distinguishes dimensions from quantity kinds. Its examples include quantities with the same inverse-time dimension that are not intended to be added interchangeably. A library modeling only dimensional exponents can therefore accept an operation whose domain meaning is wrong.

That is a broader requirement than attaching a unit label to a number. A useful domain model may distinguish frequency from another quantity with the same dimension. The type system needs enough vocabulary to represent those distinctions if it is to reject the corresponding mistakes.

The paper also distinguishes points from differences. Adding two displacements can be meaningful, while adding two absolute positions generally asks a different and often invalid question. An affine model can expose the operations appropriate to each category.

These distinctions explain why a general quantities library is more involved than multiplying by conversion constants. It needs a model of permitted operations as well as scale factors. The standardization plan seeks shared vocabulary so independently written interfaces can use that model consistently.

The proposal does not claim to prevent every numeric error. Its pitfalls section includes integer division and the limitations of underlying numeric types. Strong quantity types can reject a unit mismatch while an otherwise valid calculation still overflows or loses precision. The useful guarantee is the specific domain relationship encoded by the types, including the conversions and raw-number boundaries where that relationship would otherwise disappear.