On Sat, 14 Dec 2024, 15:28 Victor Zverovich via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> 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
>

The std::chrono formatters do for empty chrono specs.


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