LWG4090 Underspecified use of locale facets for locale-dependent std::format

[jwakely]

https://cplusplus.github.io/LWG/issue4090

LWG would like SG16 to look at this issue please

[tahonermann]

SG16 discussed this issue during its 2024-06-12 meeting. No polls were taken. SG16 will review again in the new year.

[tahonermann]

Now that I've finally published a meeting summary for the 2024-06-12 SG16 meeting, I can detail the next steps for resolving this issue.

SG16 concluded that the std::numpunct facet should be used to format integer, floating-point, and bool types and that this matches existing implementation behavior for libc++, libstdc++, and MS STL as exhibited at https://godbolt.org/z/GM6Mzv6vG. This program:

#include <format>
#include <iostream>
#include <locale>

struct test_numpunct : std::numpunct<char> {
  char do_decimal_point() const override {
	return '-';
  }
  char do_thousands_sep() const override {
	return '\'';
  }
  std::string do_grouping() const override {
	return "\1";
  }
  std::string do_truename() const override {
	return "eurt";
  }
  std::string do_falsename() const override {
	return "eslaf";
  }
};

int main() {
  std::locale loc;
  std::cout << std::format(loc, "{:L} {:L} {:L} {:L}\n", 123456, 123.456, true, false);
  loc = std::locale(loc, new test_numpunct);
  std::cout << std::format(loc, "{:L} {:L} {:L} {:L}\n", 123456, 123.456, true, false);
}

produces the following output for all three implementations.

123456 123.456 true false
1'2'3'4'5'6 1'2'3-456 eurt eslaf

Despite implementations doing the right thing, the intended behavior is under specified in the standard and [format.string.std] should be updated accordingly. A proposed resolution is needed to make further progress on this issue. I'll ask SG16 participants for a volunteer to draft wording. Once a PR materializes, I'll have SG16 confirm it matches the intent.

[jwakely]

https://godbolt.org/z/PexbszhWs extends the example to show a custom num_put facet which is not used by the std::format calls (but is used when writing to a stream directly after imbuing the stream with the locale). This confirms that implementations use numpunct directly, not via num_put.

[tahonermann]

SG16 again discussed this issue during their 2025-07-30 (rough notes) and 2025-08-27 (rough notes) meetings. The following poll was taken:

• Poll 1: LWG 4090: Adopt Victor's suggested wording as the proposed resolution
  • Attendees: 7
  • No objection to unanimous consent.

Since "Victor's suggested wording" is likely insufficient to communicate the intended changes by itself, I'll offer some elaboration. Discussion during the 2025-07-30 meeting resulted in Victor being assigned some homework to incorporate wording similar to that added by P2419R2 (Clarify handling of encodings in localized formatting of chrono types) to address LWG issue 3565. Victor completed his assignment and offered the following proposed resolution which the group then approved during the 2025-08-27 meeting.

Modify [format.string.std]p17 as indicated:

When the L option is used, the form used for the conversion is called the locale-specific form. The L option is only valid for arithmetic types, and its effect depends upon the type.

• For integral types, the locale-specific form causes the context's locale to be used to insert the appropriate digit group separator characters as if obtained with numpunct<charT>::grouping and numpunct<charT>::thousands_sep.
• For floating-point types, the locale-specific form causes the context's locale to be used to insert the appropriate digit group and radix separator characters as if obtained with numpunct<charT>::grouping, numpunct<charT>::thousands_sep, and numpunct<charT>::decimal_point.
• For the textual representation of bool, the locale-specific form causes the context's locale to be used to insert the appropriate string as if obtained with numpunct​<charT>::​truename or numpunct<charT>​::​falsename.

If the string literal encoding is a Unicode encoding form and the locale is among an implementation-defined set of locales, each replacement that depends on the locale is performed as if the replacement character sequence is converted to the string literal encoding.

@jwakely @Dani-Hub, when you have a chance, please update the LWG 4090 proposed resolution as described. I did the best I know how to do with GH markup. Let me know if you would like me to send an updated proposed resolution with proper markup via email; I'll be happy to do so. Once the issue is updated, I'll remove the SG16 label.

[jwakely]

Thanks, [LWG4090] has been updated with the new wording and passed back to LWG. Feel free to close this as well as (or instead of) removing the label.