I would be against an automatic adaptors of this nature.

Facilities such as std::format and std::basic_ostream are 2 different families of API’s, although their purpose overlap they are fundamentally different things and work under two different philosophies. And I would hope the “std::basic_ostream” family to be completely removed in the future.


From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Robin Savonen Söderholm via Std-Proposals
Sent: Thursday, December 12, 2024 2:23 PM
To: std-proposals_at_[hidden]
Cc: Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden]>
Subject: [std-proposals] Format output-streamable types?

Hi!

I enjoy the `format`, `format_to` and `print`-facilities that came with C++20 and 23 (coming from the fmt-library) but I just noticed that I can't format e.g. std::bitset. Bitset, however, do have an operator<<() defined which should be usable in the format context. So I made a very basic, proof-of-concept streambuf-derived type that could take an output iterator and wrap it inside streambuf:s API so that it was possible to call the operator<<() with an arbitrary output (char) iterator. I.e. I could do a formatter::format-function that just delegated the work to the operator<<().

I do however, wonder if it is best to just ask for the formatter to be specialised for all types that already have an operator<< (as it may arguably be slightly faster and removes the need of vtable calls inside the format function) or if it actually is desirable to have a default specialisation that says "incase of an operator<<(basic_ostreambuf<Char...>&, T const&) exist, use it for formatting". I could also think of a hybrid version where manual specialisation of std-types are made as well as the iterator-to-stream_buf type that can be used by users that do not want to re-implement their type-to-string logic.

Thoughts?

// Robin