Generate optimal formatters at compile time

[vitaut]

As pointed out by Louis Dionne in #546:

Not only could you perform the safety checks at compile-time, but you could also generate optimal code by parsing everything at compile-time.

This can make the format API as efficient as the write API and eliminate the need in the latter.

[daltonhildreth]

Perhaps I'm misunderstanding this issue, but is this even possible right now?

From my brief attempts at playing around, it would seem you need constexpr function parameters to do this. You would somehow need to split a string in a function at compile-time, yet I know no valid way to achieve this:

constexpr void split(constexpr const char* s) {
    // I'm not super familiar with fmt's internals/API
    // count_replacements would be constexpr and count the number of {}'s, or similar.
    std::array<const char*, count_replacements(s) + 1> text;
    std::array<fmt::?, count_replacements(s)> formatting;
    //...
}

The problem is this also needs to be able to run at run-time, which makes no sense for the template of std::array (or C arrays).

Perhaps this is possible with odd manipulation of template character packs? I haven't figured out a proof-of-concept for that, though.

[vitaut]

is this even possible right now?

It should be possible.

it would seem you need constexpr function parameters to do this

This is correct and {fmt} emulates them with some constexpr lambda and macro magic:

fmt/include/fmt/format.h

Line 3559 in 846c644

#define FMT_STRING(s) [] { \

You can overload on constexprness of a format string with the help of the is_compile_string trait.

[bebuch]

A better solution will be enabled by C++20:

https://wg21.link/P0732

[vitaut]

A prototype of generating optimal formatters at compile time for a subset of std::format/{fmt}'s syntax by Hana: hanickadot/compile-time-regular-expressions@13afb2c

[vitaut]

In C++20 we will be able to do this:

#include <string>

template <typename Char, size_t N>
class basic_fixed_string {
 private:
  Char data[N] = {};

 public:
  constexpr basic_fixed_string(const Char (&s)[N]) {
    for (size_t i = 0; i < N; ++i)
      data[i] = s[i];
  }
};

template <typename Char, size_t N>
basic_fixed_string(const Char (&s)[N]) ->
  basic_fixed_string<Char, N>;

template <basic_fixed_string, typename... Args>
std::string format(const Args&... args) {
  return {};
}

auto s = format<"{}">(42);

which is a pretty horrible API. Need to find a way to pass a compile-time string as an argument to make it usable.

[vitaut]

So far the most usable API is

#include <string>

template <typename Char, Char...>
struct format_string {};

template <typename Char, Char... CHARS>
constexpr format_string<Char, CHARS...> operator""_f() {
  return {};
}

template <typename S, typename... Args>
std::string format(const S&, const Args&... args) {
  return {};
}

auto s = format("{}"_f, 42);

but it requires non-standard UDL extension and passing each character as a separate template argument.

[vitaut]

With P1221 Parametric Expressions we could have the perfect API:

#include <fmt/format.h>

template <typename... Args>
constexpr bool check_format_string(std::string_view format_str) {
  return fmt::internal::do_check_format_string<
    char, fmt::internal::error_handler, Args...>(format_str);
}

using format(constexpr auto format_str, auto... args) {
  constexpr bool b =
    check_format_string<decltype(args)...>(format_str);
  return fmt::format(format_str, args...);
}

auto s = format("{}", 42); // format string checked at compile time

https://godbolt.org/z/O7rgfF

[vitaut]

The UDL version doesn't need to process character by character, it can create a static constexpr char array which can then be processed like the non-type template parameter version.

Yes, but you also need to know the types of formatting arguments. UDL doesn't have access to that and I wasn't able to return a compile-time string from the UDL without splitting it into chars. This is as far as I got: https://godbolt.org/z/pMQUfP

[foonathan]

Yeah, I deleted my comment when I realized my mistake.

[deni64k]

@vitaut Hi Victor,

but it requires non-standard UDL extension and passing each character as a separate template argument.

This syntax is a part of the C++ standard
http://eel.is/c++draft/over.literal#def:literal,operator,template_string
and
https://en.cppreference.com/w/cpp/language/user_literal#Literal_operators

// numeric literal operator template
template <char...> auto operator "" _f();

Good news, I even see it in C++11:

The declaration of a literal operator template shall have an empty parameter-declaration-clause and its template-parameter-list shall have a single template-parameter that is a non-type template parameter pack (14.5.3) with element type char.

A valid point though it requires the type to be char, though C++20 (thankfully) becomes more permissive with string literal operator template where the parameter pack is of a class type.

[foonathan]

No, it isn't. It is only valid for numeric literals, as the comment above the example states.

[deni64k]

@foonathan True, sorry for misleading. Either way, hopefully, the committee will do something about it. :)