papers VS tinyformat

What's fun is, because everything is decided in papers, we can find out why! https://github.com/cplusplus/papers/issues/884

Accepted paper here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20...

> The proposed std::print function improves usability, avoids allocating a temporary std::string object and calling operator<< which performs formatted I/O on text that is already formatted. The number of function calls is reduced to one which, together with std::vformat-like type erasure, results in much smaller binary code (see § 13 Binary code).

Additionally,

> Another problem is formatting of Unicode text:

> std::cout << "Привет, κόσμος!";

> If the source and execution encoding is UTF-8 this will produce the expected output on most GNU/Linux and macOS systems. Unfortunately on Windows it is almost guaranteed to produce mojibake despite the fact that the system is fully capable of printing Unicode

See https://github.com/cplusplus/papers/issues/557

Bringing editions to C++ failed, and I am not aware of anyone trying to tackle the issues https://github.com/cplusplus/papers/issues/631

(I could be wrong though! I follow the committee more than you may guess, but not as much as to think I know everything about what's going on.)

GitHub would not be relevant in this respect because:

* It's owned by a (single) commercial corporation, Microsoft.

* There is censorship both by content and in some respects by country of origin.

* The code is closed.

but otherwise it's an interesting idea.

The C++ standardization committee uses GitHub to track papers submitted to them, see:

https://github.com/cplusplus/papers

There was no non-approval. The facility needs more work, and the authors (and the committee) were focusing on getting print/format done first. I hope that the paper will be worked on again in the future. We will be happy to review it once there is a revision (see github for history)

For more details on what we did at the 2023-06 Varna meeting, the [GitHub issue](https://github.com/cplusplus/papers/issues/328) associated with the paper has a summary.

You subscribe to the Github issue of the proposal: https://github.com/cplusplus/papers/issues

printf has some pretty serious security implications. When I want more complicated text printing options than what is easy or terse in iostream then I use the tinyformat library.

The usual way I do I/O is via combining C++ stringstremas with either tinyformat or via an implementation of p0117 "variadic to_[basic_]string, depending on the particular need.

Haven't been able to make it work with MSVC 2012 (the earliest Windows-side compiler I need to support). I myself use tinyformat instead.

However, not all is lost. While there are libraries like {fmt} I don't pay attention to them because they are far away into The Future and unusable with my requirements (C++03 support at the earliest, work reasons). Most newfangled libs I've seen are intended for Compilers of the Future, for C++20/C++23 and the like, and with that among other reasons are not generic enough for me. Instead I just use tinyformat that lays on top of both and bridges them, not to mention the biggest sell that is rrtaining the POSIX style printf notation (why didn't {fmt} go with that is still a mystery to me).