On Thu, 12 Dec 2024 at 20:24, Robin Savonen Söderholm via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Ok, so just a proposal to add more formatter specialisations?

See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1636r2.pdf

Formatters for thread::id and filesystem::path have now been added, the rest haven't.

 
Users wanting "auto conversions" would have to implement them themselves.

I like the idea of some kind of reuse between operator<< and std::formatter, maybe opt-in. I see no reason why we would ever want to completely remove basic_ostream.

We could have a variable template like:

template<typename T>
  constexpr bool formatter_uses_ostream_insertion = false;

and then define a formatter specialization that only supports empty format specs and uses operator<< to produce a string/wstring:

template<typename T>
requires formatter_uses_ostream_insertion<T>
class formatter<T>  // ...

We could also provide the reverse opt-in, so that ostream insertion uses std::format (or std::format_to) to write to the ostream.

And we could provide a generic std::to_string(T) function which uses std::format if the type is formattable, and operator<< if that works (and is ill-formed otherwise).

There's lots of room for improvement in this space.