[2026-06 LWG Motion 6] P3395R6 (Fix encoding issues and add a formatter for std::error_code)

[notdanhan]

Fixes: #9093
Also Fixes cplusplus/papers#2187

[eisenwave]

Needs a fair amount of work, mainly converting to \grammarterm.

[eisenwave]

Some things are clearly wrong, but I could use some advice from @jensmaurer on the multi-paragraph \effects thing.

[eisenwave]

This all seems to be a scription of Effects to me, not separate paragraphs, but maybe I'm missing something. The paper does put gaps here, but idk, this is weird.

Suggested change

	\pnum
	Otherwise, let \tcode{msg} be \tcode{std::format("{}:{}", ec.category().name(), ec.value())}.
	\pnum
	If the \tcode{?} option is used then \tcode{msg} is formatted as an escaped string(\iref{format.string.escaped}).
	Writes \tcode{msg} into \tcode{ctx.out()}, adjusted according to the \fmtgrammarterm{error-code-format-spec}.
	Otherwise, let \tcode{msg} be \tcode{std::format("{}:{}", ec.category().name(), ec.value())}.
	If the \tcode{?} option is used then \tcode{msg} is formatted as an escaped string(\iref{format.string.escaped}).
	Writes \tcode{msg} into \tcode{ctx.out()}, adjusted according to the \fmtgrammarterm{error-code-format-spec}.

[jensmaurer]

I think we do have multi-paragraph \effects in some places, but having a separate numbered paragraph for every sentence is certainly non-optimal.

[notdanhan]

I have an idea

[notdanhan]

I think this works?

[jwakely]

I don't love the use of a list with no other text before or after the list. If we went this form I think the final sentence should be its own bullet. "Writes msg into ctx.out()" applies to all cases, not only when ? is used.

We could just make it all one paragraph with no paragraph breaks, but keep the innermost list for the sub-clauses of the "If the s options is used" case. So exactly as in the incoming paper, except without a paragraph break before "If the ? option is used".

[frederick-vs-ja]

Do we want a feature-test macro for formatter<error_code, charT> specialization?
CC @jwakely @brevzin @StephanTLavavej.

[jwakely]

Do we want a feature-test macro for formatter<error_code, charT> specialization? CC @jwakely @brevzin @StephanTLavavej.

Barry pinged me about this last week, suggesting that user code could polyfill formatter<error_code, charT> if the library doesn't support it yet. You can't legally provide exactly that specialization (it doesn't depend on a program-defined type) but you could do:

#ifdef __cpp_lib_format_error_code
  log("oh noes: {}", ec);
#else
  log("oh noes: {}:{}", ec.category().name(), ec.value());
#endif

Is that useful though? If you have to write the fallback version, just use the fallback version.

We do have __cpp_lib_format_path for formatter<filesystem::path, charT> though, or we could bump __cpp_lib_formatters (why didn't we do that for path? Worry about an ordering dependency?)

[StephanTLavavej]

I'm in favor of a new feature-test macro. Bumping a single macro gets really annoying when multiple features are "in flight"; it's more reasonable for a once-per-Standard thing.