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

The whole formatter specialization is not defined by forwarding to ostream
though. Describing a subset of outputs in terms of other APIs is a bit
different and just a matter of avoiding duplication in the spec.

- Victor

On Sat, Dec 14, 2024 at 8:01 AM Jonathan Wakely <cxx_at_[hidden]> wrote:

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