Allow format_to_n to be executed at compile time

[Sunday111]

Hello!
Currently fmt::format_to_n cannot be executed at compile time. I needed this functionality in one of my personal project and didn't see a reason why wouldn't it be possible so here is a PR for that.

[Sunday111]

After the first failed workflow run fixed the condition when the test runs and remove WIP change I forgot about

[dinomight]

I tried playing around with this a little bit. At least under VS17.14, this doesn't work for more complex format strings. For example,

fmt::format_to_n(buffer.data(), buffer.size(), "{}", 4);  // Your test case, totally fine.
fmt::format_to_n(buffer.data(), buffer.size(), "{}{}", 4, 2);  // Fails to compile due to an expression not being a constant.
fmt::format_to_n(buffer.data(), buffer.size(), "{:d}", 42);  // Fails to compile due to an expression not being a constant.

I suppose that's why in your test, you do multiple calls to fmt::format_to_n and also avoid any format specifiers. 😄

I would say it reduces how interesting this is, it only allows a format string of {} after all, and may be why it wasn't originally available. I think it's neat that it works, though.

[dinomight]

Windows compilation is failing because it needs #include <array> for this.

[vitaut]

Why FMT_CONSTEXPR20 and not FMT_CONSTEXPR?

[Sunday111]

It seems that destructors cannot be marked constexpr before C++ 20

[vitaut]

This shouldn't be constexpr.

[vitaut]

NVM, I thought you are trying to make a compiled version of format_to_n constexpr.

[Sunday111]

Yes, this forward declaration confused me at first and I thought an addition macro will be necessary (FMT_CONSTEXPR_IF_HEADERONLY 😄 ) but it is defined in the same header.

[vitaut]

This should go to compile-test.

[vitaut]

Thanks for the PR but there is already a compile-time version of format_to_n:

fmt/include/fmt/compile.h

Lines 497 to 498 in 577fd3b

	auto format_to_n(OutputIt out, size_t n, const S& fmt, Args&&... args)
	-> format_to_n_result<OutputIt> {

. This one is optimized for runtime and shouldn't be made constexpr (at least not yet).

[Sunday111]

@dinomight

I suppose that's why in your test, you do multiple calls to fmt::format_to_n and also avoid any format specifiers. 😄
I would say it reduces how interesting this is, it only allows a format string of {} after all, and may be why it wasn't originally available. I think it's neat that it works, though.

Well, I didn't avoid complex format strings intentionally - just wanted to make it work and see your suggestions about what cases should be working to make it decent or a reason why you don't want/need it.

@vitaut

Thanks for the PR but there is already a compile-time version of format_to_n

I am not sure I follow which version you mean. I tried a few different ways (like this to get any formatting happening at compile time with no success. So I would appreciate any suggestions 🙏.

Thank you for your review!

[dinomight]

@Sunday111 Read up on FMT_COMPILE and see if it addresses what you need. That's the version @vitaut is talking about.

fmt::format_to_n(array, N, FMT_COMPILE("{}"), 42);  // An example

@vitaut I think what they're after is an ability to generate the full, rendered string at compile time, not just compile the format string and then render at runtime. I believe the FMT_COMPILE framework only generates code to avoid parsing the format string at runtime, but it still does the actual rendering (the insertion of values) at runtime. That's at least what's suggested by the lack of constexpr on the FMT_COMPILE version of format_to_n.

I suppose the question should be, is the feature for compile time rendering interesting for {fmt} and should it work towards supporting it? I can't answer that question, I just try to contribute. 😉

This is pure conjecture, because I haven't done any perf checks, but I imagine the expensive part of {fmt} is the format parsing and not the value insertion (ignoring custom types). @Sunday111 maybe that's what @vitaut is getting at. You likely don't need compile time rendering as you can just use FMT_COMPILE to optimize the parse and the render shouldn't be a bottleneck. Granted, I also don't know your use case, so runtime rendering may not be an option.

I still think it's a fun idea and amazed at how little it took to get it to work. 😄

[vitaut]

Looks like format_to_n version that I linked to is not constexpr at the moment but a PR to make it constexpr would be welcome. Alternatively you can use format_to from fmt/compile.h, possibly with a truncating iterator, since the latter is already constexpr.

[Sunday111]

@vitaut I see. Yes, it is not constexpr, and constexpr implementation of back_inserter would be required to make it constexpr. With format_to, I will also need to write a custom iterator because I want to know how many bytes have been written and how many are required for successful rendering.

So I have to write an iterator either way, it seems.
Thank you for pointers, at least I have some options now!

[vitaut]

back_insert_iterator is constexpr in C++20.