I would also add that forwarding to ostream is almost always a bad idea and
none of the standard formatters do that for very good reasons (even basic
things like padding are incompatible because ostreams don't work with
Unicode). It is probably OK as an opt in for quick and dirty debugging code
but nothing more than that.

Cheers,
Victor

On Thu, Dec 12, 2024 at 11:49 AM Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>