Where do I forward to ostream?

lazy_string:s main purpose was not originally to just provide a means to do
format for streams, but rather make this:
```cpp
std::string str = ...; // initialised by something
...
str = lazy_format("..."...);
```
as efficient as:
```cpp
str.clear();
format_to(std::back_inserter(str), "..."...);
```
.
When the question for interoperability between new formattable types and
old ostreams arrised, I added a second use-case for it. But if that is not
desirable, then I can omit it.

// Robin

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

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