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
>