This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of LEWG status.

4284. Integer-class types should be formattable

Section: 28.5.6.4 [format.formatter.spec] Status: LEWG Submitter: Jiang An Opened: 2025-06-27 Last modified: 2025-10-21

Priority: 3

View other active issues in [format.formatter.spec].

View all other issues in [format.formatter.spec].

View all issues with LEWG status.

Discussion:

The following program doesn't compile with MSVC STL (Godbolt link). 

#include <format>
#include <ranges>

int main() {
  auto iv1 = std::views::iota(42ull, 1729ull);
  auto iv2 = std::views::iota(iv1.begin(), iv1.end());
  std::format("{}", iv2.size()); // Error
}

In MSVC STL, the type of iv2.size() is an integer-class type, and the standard hasn't guaranteed there're enabled formatter specializations for integer-class types. As a result, this program is not guaranteed to be well-formed.

Perhaps we should require enabled std::formatter specializations for integer-class types to get rid of such uncertainty and inconsistency.

Previous resolution [SUPERSEDED]:

This wording is relative to N5008.

  1. Modify 28.5.6.4 [format.formatter.spec] as indicated:

    -2- […] Each header that declares the template formatter provides the following enabled specializations:

    1. (2.1) — […]

    2. (2.2) — […]

    3. (2.3) — […]

    4. (2.?) — For each charT, for each cv-unqualified integer-class type (24.3.4.4 [iterator.concept.winc]) IntegerClass, a specialization 

      template<> struct formatter<IntegerClass, charT>;

    5. (2.4) — […]

[2025-09-18; Jiang An improves wording]

[2025-10-21; Reflector poll. Status changed: NEW → LEWG.]

Set priority to 3 after reflector poll. Send to LEWG.

"Which additional operations integer-class types should be required to support is a design question. Why format but not iostreams? What about to_chars/from_chars? All the stuff in <bit>? <utility>? <cmath>? You can show examples using any of these and claim 'uncertainty and inconsistency'."

Proposed resolution:

This wording is relative to N5014.

  1. Modify 28.5.6.4 [format.formatter.spec] as indicated:

    -2- […] Each header that declares the template formatter provides the following enabled specializations:

    1. (2.1) — […]

    2. (2.2) — […]

    3. (2.3) — […]

    4. (2.?) — For each charT, for each cv-unqualified integer-class type (24.3.4.4 [iterator.concept.winc]) IntegerClass, a specialization 

      template<> struct formatter<IntegerClass, charT>;

    5. (2.4) — […]

  2. Modify 28.5.2.2 [format.string.std] as indicated:

    -20- The meaning of some non-string presentation types is defined in terms of a call to to_chars. In such cases, let [first, last) be a range large enough to hold the to_chars output and value be the formatting argument value. If the formatting argument is of an integer-class type (24.3.4.4 [iterator.concept.winc]), the formatting argument value is as-if converted to a hypothetical extended integer type of the same signedness and width as the integer-class type first. Formatting is done as if by calling to_chars as specified and copying the output through the output iterator of the format context.

  3. Modify [tab:format.type.int] (Table 107) as indicated:

    Table 107 — Meaning of type options for integer and integer-class types [tab:format.type.int]