The implementation experience is trivially there because it's a noop on all
platforms I'm aware of. Similarly, the lack of problems with Rust / {fmt}.

Cheers,
Victor

On Tue, May 17, 2022 at 8:10 AM Peter Brett <pbrett_at_[hidden]> wrote:

> Hi Inbal,
>
>
>
> I would really like to see implementation experience, but it’s not a
> blocking issue for me.
>
>
>
> Best regards,
>
>
>
> Peter
>
>
>
> *From:* Inbal Levi <sinbal2l_at_[hidden]>
> *Sent:* 17 May 2022 13:25
>
> Thank you, Peter, I've missed that.
>
> IIUC, the second bollet about performance / lack of implementation
> experience is still a concern to you? If not, please feel free to
> elaborate, since this was also brought up by others.
>
> > implementation experience of the proposed change, and especially
> measurements of performance impact in representative usage scenarios.
>
>
>
> I would still love to see this topic addressed in the paper, but I
> believe we can now forward this paper to electronic polling.
>
>
>
> Thanks,
>
> Best regards,
>
> Inbal Levi
>
>
>
> On Tue, 17 May 2022 at 14:23, Peter Brett <pbrett_at_[hidden]> wrote:
>
> Hi Inbal,
>
>
>
> Thank you for the summary. I notice that you quoted my comments from
> earlier in this discussion. Fortunately, my concerns have been assuaged by
> subsequent author feedback.
>
>
>
> Best regards,
>
>
>
> Peter
>
>
>
> *From:* Lib-Ext <lib-ext-bounces_at_[hidden]> *On Behalf Of *Inbal
> Levi via Lib-Ext
> *Sent:* 17 May 2022 12:07
>
> 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
> <https://urldefense.com/v3/__http:/wg21.link/P2539r1__;!!EHscmS1ygiU1lA!A_oyxO-AOAoM8pc5kDqmW7nsBippSlf-WxJ-dYgKmvxLUZKJVEr-9FGv6jUBS7YmOe7WAkZXDjZot9WtSFU$>
> )
>
> 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]
> <https://urldefense.com/v3/__http:/www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2539r0.html*biblio-p2093__;Iw!!EHscmS1ygiU1lA!A_oyxO-AOAoM8pc5kDqmW7nsBippSlf-WxJ-dYgKmvxLUZKJVEr-9FGv6jUBS7YmOe7WAkZXDjZopSD-bXk$> "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):
>
> o If you support the status quo (no change): please response with *"No
> Change"*
>
> o 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
> <https://urldefense.com/v3/__https:/www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2539r1.html__;!!EHscmS1ygiU1lA!A_oyxO-AOAoM8pc5kDqmW7nsBippSlf-WxJ-dYgKmvxLUZKJVEr-9FGv6jUBS7YmOe7WAkZXDjZody6xb_8$>).
> 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
>
>