Proposed resolution:

This wording is relative to N5014.

1. Modify [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 ([iterator.concept.winc]) `IntegerClass`, a specialization

      template<> struct formatter<IntegerClass, charT>;
      

   5. (2.4) — […]

2. Modify [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 ([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]

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

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.