Hello all,
Thank you for your input! to summarize this thread:
We have 9 (+1), but also 2 (-1).
Main concerns are about precormance, lack of implementation experience,
and how (and weather) this will affect real-world applications:

   1. I'd also like to see a discussion of the performance implications. As
   I understand it, the sync_with_stdio mechanism is one part of the
   poor performance associated with iostreams.
   Why will the same consequence not apply here?
   2. I would like to hear about:
      - actual real-world application problems caused by the current {fmt}
      and Rust behaviour
      - implementation experience of the proposed change, and especially
      measurements of performance impact in representative usage scenarios.

I think it would be most helpful for the author to add a paragraph *addressing
the performance overhead* (+ benchmarks), before our last LEWG electronic
poll period, if possible. Considering the reservations, I would bring it up
with chairs to see how we proceed.

Best regards,
Inbal Levi

On Tue, 10 May 2022 at 19:44, Inbal Levi <sinbal2l_at_[hidden]> wrote:

> Yes, you're right, thank you Mark & Barry. Sorry again about that typo,
> the correction was lost in the thread.
> Re-adding the mid-discussion data so that we'll have everyone on the same
> page:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Let's* reopen this review with the new revision, R1*, proposing wording
> for* synchronizing std::print with the underlying stream:*
>
> P2539R1: Should the output of std::print to a terminal be synchronized
> with the underlying stream? (wg21.link/P2539 <http://wg21.link/P2539r1>)
> by: Victor Zverovich
>
> *Please vote +1 for supporting moving this change forward for C++23.*
>
> ***
>
> *From the Discussion:*
> To prevent mojibake std::print may use a native Unicode API when writing
> to a terminal bypassing the stream buffer. During the review of [P2093]
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2539r0.html#biblio-p2093> "Formatted
> output" Tim Song suggested that synchronizing std::print with the
> underlying stream may be beneficial for gradual adoption.
>
> *Some meta data:*
>
> - *Bottom Line: *Although the issue appears to be mostly theoretical,
> it might still be beneficial to clarify in the standard that
> synchronization is desired. Neither {fmt} ([FMT]) nor Rust (
> [RUST-STDIO]) do such synchronization in their implementations of print
> .
> - To indicate your opinion on whether a change is needed (reasoning
> is, of course, welcome):
> - If you support the status quo (no change): please response with *"No
> Change"*
> - If you support making the change *for C++23* (synchronize the
> output with the underlying steam): please response* "+1"*
>
> ***
>
> *Weekly reviews improve quality!*
> Running weekly reviews allows more iterations on each proposal, which
> hopefully, in turn, will result in more accurate and subtle fixes.
>
> Thank you for taking the time to review the proposal,
> and have a great week!
>
> Inbal Levi
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> On Tue, 10 May 2022 at 18:33, Barry Revzin <barry.revzin_at_[hidden]> wrote:
>
>>
>>
>> On Tue, May 10, 2022 at 10:17 AM Mark Hoemmen <mark.hoemmen_at_[hidden]>
>> wrote:
>>
>>> It looks like P2549R0's title is "std::unexpected<E> should have
>>> error() as member accessor" -- on the original question, though, I
>>> would vote +1, since I would want new introductions of std::print into
>>> existing code to interoperate correctly.
>>> mfh
>>>
>>
>> Yeah it's supposed to be P2539 (
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2539r1.html).
>> The original email got this right, just the subject had a typo. This is why
>> it's good to always include the title (thanks, Inbal!) so it's obvious
>> which paper we're discussing (which, in this case, clearly the std::print
>> synchronization one with just the wrong number... rather than the
>> unexpected one with the wrong title). Very difficult to typo the whole
>> title. The keys aren't exactly right next to each other...
>>
>> Barry
>>
>