This past year we were porting Elemental (PC game) to 64-bit so it's pretty old code. There are a gazillion different string types in it (sprintf and beyond).
A classic example of where they didn't do this right is SystemVerilog arrays. You cannot have busses with zero wires in them. "Why would you need that?" somebody probably said... What's the point of a bus with no wires? Well imagine you write a SystemVerilog module with some memory interface like this:
module foo (
input var logic [31:0] i_addr,
input var logic [7:0] i_data,
input var logic [3:0] i_user_data,
...
module foo #(
parameter A = 32,
parameter D = 8,
parameter U = 4
) (
input var logic [(A-1):0] i_addr,
input var logic [(D-1):0] i_data,
input var logic [(U-1):0] i_user_data,
There is the conflict - if I write useless code I want the compiler to stop me. This is very different from generic code where sometimes a part simplifies to useless code in some particular context even though the whole is useful. Anytime the system can tell the difference between these two I want them treated different.
Telling the difference between useless code and generic code that has a useless form in this context is often not a solvable problem. There are also cases where if we had known better 40 years ago we would have made a different choice, but it is too late now. However I think the rules stands: the system should reject useless code when that is what someone writes even if the code otherwise parses correctly.
...only to then convert it back to UTF-16 for WriteConsoleW(), which std::print() usually calls (unless not running in a console) (https://github.com/microsoft/STL/blob/488e7953685722d2d6666f...).
Silently corrupting the path seems an odd choice in this day and age, when WTF8 has existed for many years and fixes this round trip bug / security vulnerability
This is great but it sounds like it doesn't work for floats yet
> For now, compile-time std::format covers integers, strings, and diagnostics well, with floating-point support waiting on a separate paper (P3652) to make the floating-point <charconv> functions constexpr.
To the best of my knowledge fmtlib does implement constexpr formatting for float and double, but not long double.