P2418 proposes forwarding formatting arguments for generator-like types

Observing a lazy sequence can require changing the sequence's state. That makes a const reference an unsuitable universal interface for formatting. If the sequence is also noncopyable, a formatter cannot solve the problem by copying it and iterating the copy. The formatting function has already restricted the access needed to obtain the values.

Victor Zverovich's P2418R0, dated August 7, proposes changing formatting functions to take forwarding references. The motivating types include the proposed std::generator. The change is about permitting the required access to an argument, and it reaches through the formatting API into the requirements on formatter specializations.

I find this proposal useful because a const-reference interface can look more general than it is. It avoids copying an ordinary object, but it also imposes const access. For a sequence backed by suspended computation, obtaining the next value can be a state-changing operation even when the consumer only intends to print it.

Range formatting exposes the restriction

The earlier P2286R0 range-formatting proposal identifies the problematic combination. Some views are not const-iterable. When they are copyable, a formatter can sometimes make a view or copy that supports traversal. A move-only view without const iteration has neither route available.

P2418 proposes changing format and related entry points from const-reference packs to forwarding-reference packs. The argument's constness and reference characteristics can then inform the formatting path instead of the outer interface imposing const access on every object. This is necessary for a formatter that must traverse mutable iteration state.

The change does not independently provide a formatter for every possible generator. Type-specific formatting support still has to exist. Removing the argument-access restriction allows such support to work. It does not define a textual representation for all new range types. Range-formatting design and argument transport remain related but distinct pieces. A library needs both an applicable formatter and a way to pass the sequence through to that formatter.

The proposed signatures include the locale-taking overloads and the narrow and wide character forms. Output-oriented functions such as format_to and format_to_n receive corresponding changes, as does formatted_size. Applying the rule consistently matters because asking for the output size can need the same ability to observe an argument as producing the output.

Formatter requirements preserve ordinary behavior

P2418 distinguishes basic formatter requirements from the stronger ordinary formatter requirements. Its proposed argument handling can use const formatting when that is supported and non-const access when necessary and permitted by the argument. A const caller-owned object does not become mutable simply because the function accepts forwarding references.

The wording therefore does more than replace one parameter spelling. It updates type normalization for selecting formatter specializations and the machinery that stores user-defined arguments. That machinery must preserve enough qualification information to call the correct formatting operation. Otherwise the public signature change would still encounter a const restriction deeper in the implementation.

This is a common integration issue in generic libraries. An outer forwarding-reference function can accept an object while an erased internal representation loses the property that made it acceptable. The proposed changes follow the argument through the internal handle, rather than assuming that deduction at the entry point is sufficient.

I prefer that complete account. A signature can advertise support that the implementation cannot provide if later layers discard the required access. The paper identifies those layers explicitly and gives implementation experience from {fmt}, which has used forwarding-reference arguments since its 6.0 release.

Bit-fields lose direct binding

The compatibility cost concerns bit-fields. P2418 gives a structure containing a one-bit integer field and shows that passing the field directly to format becomes ill-formed. Supporting that case was one reason for the original const-reference design. The broader access needed by generator-like objects therefore conflicts with an existing accepted argument form.

The paper provides a short workaround. Applying unary plus or casting the field to an ordinary integer creates a value that can be passed through the new interface. In a formatting call, the relevant expression can be written as follows:

std::format("{}", +object.bit);

This is an explicit value conversion at the call site. It is appropriate for the bit-field case because the formatting operation needs its numeric value, not a reference to independently addressable storage. The proposal documents the break instead of claiming the forwarding-reference interface accepts every call accepted by the const-reference interface.

The paper also notes a possible lifetime benefit for range joiners. Preserving argument characteristics can let a joiner reject an object that would otherwise retain a reference to an expired temporary range. That is a possibility enabled by the interface change, not a promise that every dangling reference becomes detectable. The formatter and joining utility still need to specify how they use the information the argument interface preserves.