fmtlib update

[vitaut]

First, great work on formatxx and thanks for kind words about the fmt library (previously cppformat)! Just wanted to give you a quick update and point out that in the recent versions of the library the part

the compilation time overhead of including its primary header is pretty large, and its support for formatting user-defined types relies on std::ostream wrappers (which are neither lightweight includes nor are they runtime efficient)

no longer applies because the ostream support has been moved to a separate header and the most heavy includes have been removed. There are still some non-essential headers included such as vector and utility which I plan to get rid of in the next release but I doubt they add much to the compile time. There has also been substantial compile-time speed optimization work as part of fmtlib/fmt#243.

Could you by any chance update the README file?

[vitaut]

BTW would love to learn about your thoughts on error handling without exceptions.

[seanmiddleditch]

@vitaut - sure, I'm happy to update, will do when I get a chance. :)

My thoughts on errors are complicated, and partly come down to what a user is using formatting for.

For logging or UI (my primary use cases) I would the formatter to output as much as possible but make it obvious that it couldn't do everything. The existing behavior in formatxx accomplishes that goal.

For uses that might be more security-sensitive, like forming HTTP requests/payloads or filenames, we definitely need a way to programmatically check for errors. My plan there is to provide an overload that can return something like a std::error_code to indicate (at least one) failure and as much relevant info as I can (which argument, etc.).

For overflow e.g. in the fixed_writer I'm tempted to make that a property of the writer itself, but the format call could certainly check for that and return an error code as well to indicate truncation has been detected.

[seanmiddleditch]

Turns out I had time now as I wait for a CI job to complete. :) Let me know if I missed anything.

[vitaut]

Looks accurate now, and thanks for sharing your vies on error handling! I plan to look into how this is done in the fmt library at some point. Fundamentally there is nothing preventing the library from providing an alternative API based on error codes rather than exceptions.