[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.

[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.