Analyze universal-formatter example

[FranciscoThiesen]

@lemire found this issue here: https://github.com/bloomberg/clang-p2996/issues/37

That mentions the universal_formatter (which does something similar to the serialization we are currently able to do).

Some aspects that I want to research:

• Are there any useful patterns for us to adopt to simplify our codebase?
• What would be the ergonomic impact to change to the universal_formatter approach (i.e need to declare the formatter for every struct used in the process (bad) ).

[lemire]

One of the benefit of looking at this example is that it follows closely what people seek to do with the standard.

[Yaraslaut]

Hi, I've been playing around with reflections to serialize into different formats and I think I can add something to this point:

What would be the ergonomic impact to change to the universal_formatter approach (i.e need to declare the formatter for every struct used in the process (bad) ).

See https://godbolt.org/z/nG7ad4f9T Basically you can make compiler instantiate formatter as long as you can encapsulate it inside function

[FranciscoThiesen]

@Yaraslaut pretty cool example and indeed you don't need to explicitly instantiate the formatter. Do you think/know if there is any benefit out using this formatter approach versus what we are currently doing?

[Yaraslaut]

I looked at fast_to_json_string and think that the only difference is the lack of handling of base classes.
Also, reflections allow you to make formatting a bit more generic so you can serialize into different formats (https://github.com/Yaraslaut/form?tab=readme-ov-file#serialization-into-different-formats)

As for universal_formatter you can add something like

template<typename T>
struct std::formatter<T> : universal_formatter{};

and then you can print any structure with std::print("{}",S{})