Ah... I've started working on this in an alternative way which derives basic_format_string from _Basic_format_string and only adds it in C++23 mode. Although it seemly needs additional test coverage for the newly added get member function.

Or alternatively, should we implement basic_format_string as an alias template to avoid additional non-reservered names in C++20 mode?
Although this is currently non-conforming, but IMO it's reasonable to form a DR (targeting C++23 only) to allow basic_format_string to be an alias template.

I will implement the alternative approaches if I have to, but I really hope that we don't need them.

Maintainer decision needed: implementing this unconditionally will introduce these new identifiers in C++20 mode, making conflicts possible.

My initial reaction is that this should be guarded for C++23, as we generally consider the introduction of new identifiers to be a bright line. However, perhaps the signature change is sufficiently invasive, and the risk of conflict sufficiently low, that implementing this "downlevel" would be reasonable. Certainly, something that affects only C++20 is much less risky than something that goes back to C++14/17.

One more note: we won't be backporting further changes to VS 2019 16.11.x except in highly critical cases; I believe that this is an additional reason to avoid changing C++20 behavior.

Note that P2419R2 "Clarify handling of encodings in localized formatting of chrono types" was implemented for C++20. If P2508R1 is guarded for C++23, then it needs to be decided whether __cpp_lib_format will have value 202207 in C++20 mode.

It's a bit strange that while P2419R2 looks like a DR (resolving LWG-3565) but P2508R1 doesn't, both papers bump the same feature-test macro. I plan to contact LWG for clarification.

Charlie and I talked about this at the weekly maintainer meeting and we're ok with the current approach of implementing this in C++20 mode - thanks!

It's a bit strange that while P2419R2 looks like a DR (resolving LWG-3565) but P2508R1 doesn't, both papers bump the same feature-test macro. I plan to contact LWG for clarification.

There is currently a discussion on the SG-10 mailing list about this and there is an LWG issue
https://cplusplus.github.io/LWG/issue3750

FYI libc++ has also implemented this paper in C++20 mode. This is shipped in LLVM 15.

FYI libc++ has also implemented this paper in C++20 mode. This is shipped in LLVM 15.

Yeah, if libc++ already did it in C++20 mode it seems like we should too. Gating it behind C++23 is likely to cause much more pain for people using multiple compilers than the new identifier.

In libc++ we never shipped the exposition only version. So it was easy to decide to do it this way.

Looks good - I see nothing missing here, and the risk of linker errors when mixing old and new code is low. (Previously, the type couldn't be directly named, so it appeared as a function parameter and would be implicitly constructed. The risk would be higher if functions could have easily returned the type.)

The only thing I considered commenting on was that the struct begins with a public: section, when we usually rely on the default, but this is a defensible style choice (as the exposition-only data member is private: which is good). No change requested.

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

Thanks for implementing this C++23 feature and increasing <format> usability! 😻 🎉 🚀