Fmt: Usage of fmtlib in <format>/std::format implementations

[barcharcraz]

We (the Microsoft STL) are going to be basing our implementation of std::format on your library (unless you have strong objections). We probably won't be submoduling fmt directly however because of the following reasons:

• ABI compatibility
  We need to maintain ABI forever, and fmt does change the layout of things like format_arg_store occasionally
• workarounds and c++11 support
  we don't need these, so we can eliminate some code / implement things in simpler ways.

We are interested in tracking fmt and adopting any performance improvements you come up with if we can. I'm posting the reasons we can't directly use the library just so you know about them, I'm not requesting you have a stable ABI (that would not be a good idea) or remove support for old compilers. In fact I'm not requesting much of anything, just letting you know what we're up to.

[vitaut]

Sounds great, thanks for letting me know!

From my side I've been improving compatibility between {fmt} and std::format in the last few releases, so hopefully this will make your job easier =).

[barcharcraz]

ah wonderful, If you're interested we can exchange test code as we both work toward conformance.

[vitaut]

@barcharcraz, regarding the ABI, I wonder if it would be possible to have non-type-erased function templates (std::format, std::format_to, std::format_to_n and std::formatted_size) not be part of the ABI so that we could add compile-time format string checks to them in the future?

[barcharcraz]

everything is part of ABI, we won't like, explicitly specialize them or anything, but we can't break previously valid code with just a redist update.

I don't think adding such compile time checks to those functions should be an ABI problem since that's a pure behavior change, and the worst case would be customers not getting those checks. We'll think about compile time checks before we release though.