Enable constexpr support on format

[bebuch]

I just tried calling fmt::format in a constexpr context (static_assert) and found that it doesn't work. Since C++20 has constexpr support for std::string, it should also be possible to add constexpr support to fmt::format.

#include <string_view>
#include <fmt/core.h>

using namespace std::literals;
static_assert(fmt::format("{}", 5) == "5"sv);

• https://godbolt.org/z/q48YxY7sE

Is there anything against this?

[vitaut]

It can't be done in the core API but making the format overload in fmt/compile.h conditionally constexpr should be doable:

fmt/include/fmt/compile.h

Lines 521 to 524 in 62ff4e1

	template <typename S, typename... Args,
	FMT_ENABLE_IF(detail::is_compiled_string<S>::value)>
	FMT_INLINE std::basic_string<typename S::char_type> format(const S&,
	Args&&... args) {

A PR is welcome.

[alexezeder]

IIRC, the problem is actually that you cannot simply create std::string and make it escape a constant-evaluated context, since all allocated memory with new operator should be deallocated. This is according to P0784 - More constexpr containers.

Ok, I see, there is no problem with the provided example, since static_assert is the expression.

[bebuch]

I would be a problem if you mark the function consteval, so it is always evaluated at compile time. With constexpr it's only compile time evaluated, if the hole expression is in a compile time context. I'm quiet sure this should never make problems ;-)

[alexezeder]

Here is the problem example that I was referring to - https://godbolt.org/z/Y4WbPYzbx. Thus, format() cannot be called in a constant-evaluated context here because the result is escaping constant-evaluated context apparently. But with static_assert it works because entire usage is inside a constant-evaluated context, nothing escapes.

[bebuch]

If I'm not wrong, you actually can use it in this context. You just can't use the variable abc in a non constexpr context. But that's the case for any constexpr std::string so it's nothing special about creating ît by format. Also note that this would never break backwards comparably, because it's currently not possible to initialize a constexpr variable from format.

The constexpr should only enable new use cases without breaking any existing code.

There are cases (like constinit variables) where you can't use it because of the compile time / run time restriction, but this shouldn't be a problem because they don't work at the moment as well.

[vitaut]

Closing as it is possible to achieve the same effect via existing APIs (format_to) but a PR to add optional constexpr support to format would be welcome.

[bebuch]

I just want to note that the compiler features constexpr cast from void* P2738 and User-generated static_assert messages P2741 have just been voted into C++26. Both refer explicitly to constexpr std::format. 🎉

fmt/std::format in static_assert error messages would be dream! 😁

[cor3ntin]

Clang (trunk, 17) supports both P2738 and P2741.

Better constexpr support in fmt would indeed be excellent. Right now it's a bit cumbersome https://compiler-explorer.com/z/rK7sdPj9j

constexpr auto msg() {
    char c[100] = {};
    fmt::format_to(c, FMT_COMPILE("The answer is {}."), 42);
    return std::string(c);
};
static_assert(false, msg());```

[mpusz]

This might be useful for some of you:

consteval std::string constexpr_format(auto fmt, auto&&... args)
{
  std::string text;
  fmt::format_to(std::back_inserter(text), fmt, std::forward<decltype(args)>(args)...);
  return text;
};

static_assert(false, constexpr_format(FMT_COMPILE("The answer is {}."), 42));

It is a pity that fmt::format does not do it by default.