Date: Mon, 4 Apr 2022 14:36:07 -0500
+1, it is important that this work. Among other things, it is necessary for
safe, incremental adoption of format.
Barry
On Mon, Mar 28, 2022 at 4:18 PM Tim Song via Lib-Ext <
lib-ext_at_[hidden]> wrote:
> As the paper mentioned, I brought this up during the LWG review, so it
> should be unsurprising that I think this should be synchronized at least
> for ostreams.
>
> In one of our codebases, where formatting started with iostreams and
> gradually shifted to {fmt}, there are lots of code of the form:
>
> struct A {
> int a; int b;
> friend std::ostream& operator<<(std::ostream& os, A const& a) {
> fmt::print(os, "{{a={}, b={}}}", a.a, a.b);
> return os;
> }
> };
>
> This seems like a perfectly valid way to implement operator<< to me -
> except that it doesn't work if fmt::print (and now std::print) can
> sometimes bypass things in os's buffer. With iostreams in particular, <<
> naturally encourages writing partial lines:
>
> A a{2, 4};
> std::cout << "A is " << a << '\n'; // might print "{a=2, b=4}A is "
>
> And having this only happen when writing to a terminal means that it's
> going to be hard to catch in tests - normally those tests would format
> something into a buffer and compare with the expected output, which won't
> engage the reordering case.
>
>
> On Mon, Mar 28, 2022 at 12:11 PM Inbal Levi via Lib-Ext <
> lib-ext_at_[hidden]> wrote:
>
>> * Correction to the title - paper is *P2539*
>>
>> On Mon, 28 Mar 2022 at 20:09, Inbal Levi <sinbal2l_at_[hidden]> wrote:
>>
>>> Hello all,
>>> Today we have a paper in a bit of a different format (😉) -
>>> this is an *Info* paper, which the fmt library author wrote to notify
>>> LEWG of the current behaviour.
>>> Currently there's *no action* suggested in the paper, but we would like the
>>> author to *get an indication on the amount of support for the status
>>> quo, as well as **whether a change is needed.*
>>>
>>> P2539R0: Should the output of std::print to a terminal be synchronized
>>> with the underlying stream? (wg21.link/P2539)
>>> by: Victor Zverovich
>>>
>>> ***
>>> *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: *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 think a change is needed (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
>>>
>> _______________________________________________
>> Lib-Ext mailing list
>> Lib-Ext_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
>> Link to this post: http://lists.isocpp.org/lib-ext/2022/03/22839.php
>>
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2022/03/22841.php
>
safe, incremental adoption of format.
Barry
On Mon, Mar 28, 2022 at 4:18 PM Tim Song via Lib-Ext <
lib-ext_at_[hidden]> wrote:
> As the paper mentioned, I brought this up during the LWG review, so it
> should be unsurprising that I think this should be synchronized at least
> for ostreams.
>
> In one of our codebases, where formatting started with iostreams and
> gradually shifted to {fmt}, there are lots of code of the form:
>
> struct A {
> int a; int b;
> friend std::ostream& operator<<(std::ostream& os, A const& a) {
> fmt::print(os, "{{a={}, b={}}}", a.a, a.b);
> return os;
> }
> };
>
> This seems like a perfectly valid way to implement operator<< to me -
> except that it doesn't work if fmt::print (and now std::print) can
> sometimes bypass things in os's buffer. With iostreams in particular, <<
> naturally encourages writing partial lines:
>
> A a{2, 4};
> std::cout << "A is " << a << '\n'; // might print "{a=2, b=4}A is "
>
> And having this only happen when writing to a terminal means that it's
> going to be hard to catch in tests - normally those tests would format
> something into a buffer and compare with the expected output, which won't
> engage the reordering case.
>
>
> On Mon, Mar 28, 2022 at 12:11 PM Inbal Levi via Lib-Ext <
> lib-ext_at_[hidden]> wrote:
>
>> * Correction to the title - paper is *P2539*
>>
>> On Mon, 28 Mar 2022 at 20:09, Inbal Levi <sinbal2l_at_[hidden]> wrote:
>>
>>> Hello all,
>>> Today we have a paper in a bit of a different format (😉) -
>>> this is an *Info* paper, which the fmt library author wrote to notify
>>> LEWG of the current behaviour.
>>> Currently there's *no action* suggested in the paper, but we would like the
>>> author to *get an indication on the amount of support for the status
>>> quo, as well as **whether a change is needed.*
>>>
>>> P2539R0: Should the output of std::print to a terminal be synchronized
>>> with the underlying stream? (wg21.link/P2539)
>>> by: Victor Zverovich
>>>
>>> ***
>>> *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: *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 think a change is needed (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
>>>
>> _______________________________________________
>> Lib-Ext mailing list
>> Lib-Ext_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
>> Link to this post: http://lists.isocpp.org/lib-ext/2022/03/22839.php
>>
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2022/03/22841.php
>
Received on 2022-04-04 19:36:21