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

3641. Add operator== to format_to_n_result

Section: 28.5.1 [format.syn] Status: NAD Submitter: Mark de Wever Opened: 2021-11-14 Last modified: 2026-06-10

Priority: 3

View all other issues in [format.syn].

View all issues with NAD status.

Discussion:

During the 2019 Cologne meeting the papers P1614R2 "The Mothership has Landed" and P0645R10 "Text Formatting" have been accepted. P1614R2 adds operator== to to_chars_result and from_chars_result. P0645R10 adds a similar type format_to_n_result without an operator==. LWG 3373(i) reaffirms these three types are similar by ensuring they can be used in structured bindings.

It seems due to accepting P1614R2 and P0645R10 during the same meeting the addition of operator== wasn't applied to format_to_n_result. I propose to add operator== to format_to_n_result to keep these types similar.

The Out template argument of format_to_n_result is unconstrained. Since it's returned from format_to_n it's indirectly constrained to an output_iterator. An output_iterator doesn't require equality_comparable, thus the defaulted operator== can be defined deleted.

[2022-01-30; Reflector poll]

Set priority to 3 after reflector poll. Several votes for NAD. Unclear why to_chars_result is equality comparable, but whatever the reason, this is unrelated to them and doesn't need to be.

[2026-06-10 Status changed: New → NAD.]

Most uses of this comparison would be undefined, so adding it would have negative benefit.

Proposed resolution:

This wording is relative to N4901.

  1. Modify 28.5.1 [format.syn], header <format> synopsis, as indicated:

    […]
template<class Out> struct format_to_n_result {
  Out out;
  iter_difference_t<Out> size;
  friend bool operator==(const format_to_n_result&, const format_to_n_result&) = default;
};
[…]