This is kinda just a frustration rant, but I'm very disappointed with the changes in the fmt library, which are going to break my logging wrappers around it, and probably force me to find another solution soon (maybe even going back to using "dumb" C-style variadic macros again).
There are two main things which are frustrating me:
1. fmt::sprintf has been deprecated
2. fmt::format can no longer be used in wrapper functions, with compile time checking
The first issue is understandable, but is also a case of throwing the baby out with the bathwater. I get that it cannot be perfectly performance optimal, but breaking the ability to use printf-style formatting in the future will cause people with lots of format strings in this format to look elsewhere. In this case, maybe back to "dumb" C-style printf. Is that really better than slightly worse runtime performance with type and runtime safety? No, that's idiotic... but that's what the fmt library developers are apparently pushing for.
The second is more complicated: the new version broke this, but maybe because MSVC's compiler implementation is not current with C++23+? Unsure. String literals no longer work as format strings, but more significantly, you apparently cannot call
fmt::format with parameters where the parameter values are not known at compile time, as is the case with almost every actual logging usage call (you need to wrap the format string arg in fmt::runtime, and give up compile time parameter type checking, apparently). This is a strict regression from fmt 10.x. Again, this seems like an asinine decision from the library authors, but maybe there's some idealized goal they are going for here; whatever the case, previous benefits are going away, which is making using the library a much less attractive proposition.I'm curious if there is any fork attempt of the library to not break the above, which might be supported in the future, or if I will just need to migrate away from it at some point.
https://redd.it/1p4yf4v
@r_cpp
