I'm experimenting with FMT_COMPILE lately and here are a few points about it that are interesting for me. Note that my assumptions below can be wrong.
-
FMT_COMPILE (or I should probably say compile-time API) doesn't support arg_id. There are no tests for that and when I try to use arg_id in this API then a compiler is trying to tell me that it's unable to do this. I don't think it's impossible to implement but it just takes some time.
-
The compilation error with arg_id inside of FMT_COMPILE, as well as other non-valid for compile-time API format string I suppose, is non-intuitive. Here is an example: https://godbolt.org/z/ha38a6
At least for me, the error that there is no type is non-intuitive. Especially when there are implemented handling inside parsing code:
and strange check that allows the compiler to continue its journey to that no ::type error:
|
if constexpr (std::is_same<remove_cvref_t<decltype(result)>, |
|
detail::unknown_format>()) { |
|
return detail::compiled_format<S, Args...>(to_string_view(format_str)); |
Of course, I can miss some case where it should go that path, so let me know.
-
The situation with a format string that has fewer replacement fields than the number of arguments that passed to the format function is valid. For example here are non-failing calls:
fmt::format(FMT_COMPILE("{}"), 42, 42);
fmt::format(FMT_COMPILE(""), 42);
The same usage on Compiler Explorer.
But the runtime API also sticks with this behaviour, even with FMT_STRING checks, so maybe there is some explanation for that.
I'm experimenting with
FMT_COMPILElately and here are a few points about it that are interesting for me. Note that my assumptions below can be wrong.FMT_COMPILE(or I should probably say compile-time API) doesn't supportarg_id. There are no tests for that and when I try to usearg_idin this API then a compiler is trying to tell me that it's unable to do this. I don't think it's impossible to implement but it just takes some time.The compilation error with
arg_idinside ofFMT_COMPILE, as well as other non-valid for compile-time API format string I suppose, is non-intuitive. Here is an example: https://godbolt.org/z/ha38a6At least for me, the error that there is no
typeis non-intuitive. Especially when there are implemented handling inside parsing code:fmt/include/fmt/compile.h
Line 544 in 4a6eadb
and strange check that allows the compiler to continue its journey to that no
::typeerror:fmt/include/fmt/compile.h
Lines 573 to 575 in 4a6eadb
Of course, I can miss some case where it should go that path, so let me know.
The situation with a format string that has fewer replacement fields than the number of arguments that passed to the format function is valid. For example here are non-failing calls:
The same usage on Compiler Explorer.
But the runtime API also sticks with this behaviour, even with
FMT_STRINGchecks, so maybe there is some explanation for that.