{fmt} is provided as a lib, but not included/linked in the project (at least macOS)

[artificiel]

I'm in favour of using {fmt} (more than std::format) but as the title says, while the library is provided as compiled lib, it's not being included in the projects, which is sort of ambiguous...

also somehow related (not sure if it's an issue in itself) but frameworks contain Headers//.h -- why are compiled lib headers duplicated in another parallel include/*.h dir?

[NickHardeman]

@artificiel it seems that some of the functionality in fmt is included in C++20. For the sake of reducing dependencies and build complexity; requiring C++20 might be easier to adopt .
What is the functionality / aspects of fmt that you prefer over std::format?

[dimitre]

+1 for removing it for 12.1
after that it can replace unsafe ofLog backend

[artificiel]

@NickHardeman I will not fight for {fmt} but here are a cluster of reasons/criteria (not all specific to {fmt} but also addressing libs in general) that define the outline of a decision process:

1. practically, std::format is only a subset of {std} — more is coming in C++23 and 26, but it's a slow and sporadic process;

2. {fmt} is part of the newer breed of library projects (let's call them "post-boost era") where the design is around providing nimble freestanding code, often headers-only (that's how I use {fmt}) ensuring integration in painless and voluntary (you can always decide to stick to a given version) — the fact the std::format is standardized in interesting to encourage the displacement of snprintf and << streams, but not so much from the perspective of {fmt} users who already have something better than whatever is in the standard (because it's evolving actively) — as such, maintaining the dependency should be near zero-cost;

3. the ISO standardization process is showing it's limits... let's consider: the US Gov downgraded C++ for mission-critical applications; Google more or less left C++ behind (Carbon is a hoax); Linux allows Rust in the kernel (and no C++) — just there we have 3 very different groups sharing the characteristic of not being satisfied with the C++ direction... which can directly be attributed to the ISO leadership (ex: the upcoming Security Profiles are being shoved in, and satisfy mostly large established codebases, not new efforts which would benefit more from recent concepts like compile time safety checks (Rust, Zig, etc). I'm not anticipating an imminent ISO meltdown, nor proclaiming some "openC++" will suddenly emerge, but ISO C++ is actually a very non-open thing...

4. another complain on ISO C++ is that they attempt integrating libraryish functionalities, but with the ABI policies, it means once something makes it into an implementation, it's mostly locked in place forever, preventing evolution. so there is pressure into focussing the standard process on the language itself and things like reflection, and if something can be done in 3rd party without compromise, leave it there. it also removes work for compiler vendors. things like std::filesystem are a bit different as the interaction with the OS is fundamental to the functionality, in which case you're happy the compiler vendors are forced to keep up with the OSes; with {fmt} it's pretty much "pure code" and handling windows vs linux is pretty much the same.

[artificiel]

oops closed by accident and can't reopen!

[NickHardeman]

@artificiel thank you for the thorough explanation :)

[artificiel]

also! (back to more practical)

5. on macOS libc++ feature availability depends on inclusion which is tied to an OS version. one example: even though a C++23 OF project can target the current OF lowest-supported macOS10.15, to_chars float conversion requires 13.3 because that's when apple's libc++ delivered the support. the whole {fmt} will run on 10.15.

[danoli3]

its easy to just add it to the project

[danoli3]

okay done