November 13, 2020·4 min read·engineeringcppstandardsintegerstemplates

WG21 adopts its first C++23 changes in a virtual plenary

WG21's first virtual plenary adopts the first C++23 changes. Literal suffixes for size types show how a small language addition can resolve recurring template and loop problems.

A committee can continue discussing proposals without having a way to adopt them into its working draft. WG21's first virtual plenary supplies that missing step after months of online subgroup work. Herb Sutter's November 13 report describes the Monday meeting's adoption of the first C++23 changes, including a language addition for size-related integer literals.

This is the beginning of the next working draft's technical changes. It is not a release announcement for an implemented library. The distinction matters for examples using the adopted syntax, which describe the draft direction rather than facilities every current compiler already supplies.

C++'s accumulated complexity makes small, concrete improvements interesting to me. A size-related literal suffix addresses a recurring mismatch between ordinary integer literals and the types used by container interfaces. Its value is easier to assess through the exact type problem than through a general claim of modernizing loops.

A zero literal still has a type

JeanHeyd Meneide and Rein Halbersma's P0330R8 proposes suffixes for size_t and its corresponding signed type. The adopted direction includes forms such as 0uz. An integer's numerical value alone does not describe its behavior in deduction and mixed arithmetic.

A loop initialized with auto i = 0 deduces an ordinary integer type from the initializer. That does not make it the type returned by a container's size operation. The source can therefore introduce a signedness or type mismatch even when the initial numerical value is unremarkable.

The draft syntax expresses a different initializer type.

for (auto i = 0uz; i < values.size(); ++i) {
    consume(values[i]);
}

This example illustrates the newly adopted C++23 direction for a container with a matching size type. It does not claim that every size-returning user-defined interface uses size_t.

The suffix also avoids guessing which conventional unsigned type corresponds to the platform's size type. A spelling tied to unsigned long describes that particular type. It cannot establish a universal relationship with the type used for object sizes.

The mismatch can prevent deduction

The proposal also discusses a declaration that initializes multiple variables under one auto. If the initializers imply different types, the source has a deduction problem before the loop even runs.

This is a useful example because it separates numerical compatibility from type agreement. A zero value can be representable in both types, yet the declaration still asks for a consistent deduction that its initializers do not provide. The source needs to express the intended common type.

A size-related literal makes that intent concise when the other initializer has the matching size type. It does not require a cast whose only purpose is to make the literal participate in the correct type family. The declaration can state the relationship at the place where the value originates.

This distinction also affects a generic helper accepting a bound and a starting value. If it deduces one template parameter from both arguments, a literal of an unrelated type can make the call fail even though the value fits. Expressing the size type directly can let the caller state the intended agreement without changing the helper to accept unrelated combinations.

For a reader, that is useful information. The suffix identifies the role of the literal before any surrounding conversion. The source then needs less reconstruction to explain why a template or declaration accepts the two values together.

A suffix does not repair the algorithm

The new spelling addresses the type of a literal. It does not establish that an index stays inside a container's bounds or that a container remains unchanged during iteration. Those requirements belong to the algorithm and its ownership model.

This distinction matters particularly when a programmer uses the suffix to remove a warning. A cleaner comparison does not prove that every operation in the loop is valid. The change should be explained as expressing the intended type, with the rest of the loop's contract considered separately.

Signedness also remains a design choice. Some calculations need to represent negative differences, while sizes describe another role. The proposal's associated signed type gives the language a related spelling without making those roles identical.

A useful interface should say which role a value has. Counts and differences can require different validity conditions even when their representations overlap. A literal suffix helps identify a representation choice, while naming and documentation explain the application's meaning.

Small library interfaces can remove incidental expressions

The plenary also adopts a string containment facility. The P1679R3 proposal describes contains for string interfaces. Containment directly asks whether the specified text occurs, instead of requiring callers to translate a search result into a Boolean condition themselves.

This is another bounded interface improvement. A caller wanting a position still needs a search result with that information. A caller wanting presence can use an operation whose result matches that question.

The change can reduce opportunities to misread a search position as a truth value. A valid match can occur at the beginning, so the numerical result's ordinary Boolean conversion is not the intended presence test. A named containment operation gives that test its own interface.

I prefer these additions when they reduce recurring incidental code without creating another independent conceptual system. A literal can state its intended type, and a string operation can state the question the caller is asking.

Virtual work now has an adoption boundary

Sutter's report distinguishes the months of subgroup discussion from the full-committee meeting that formally adopts changes. The virtual plenary turns ongoing design and wording work into revisions of the working draft. That makes the process's outcome more definite than a collection of proposals still under discussion.

For users, the adopted changes remain draft work whose implementation status needs its own evidence. The immediate result is that WG21 has an operational route for advancing the revision while meeting remotely. The size-literal addition gives that first set of changes a concrete source-level effect that a programmer can understand through deduction and type agreement.