Hey folks,
Victor kindly provided a new revision with wording to flush the underlying
stream upon writing
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2539r1.html

Please provide feedback on the paper/wording.
Given the support for the direction last time, if we don't hear objections
or new information, we will start a motion to send this paper to electronic
polling.


Thanks,
Have a great day,

Corentin.




On Fri, Apr 8, 2022 at 11:10 AM Jonathan Wakely <cxx_at_[hidden]> wrote:

> +1
>
> On Mon, 28 Mar 2022, 18:09 Inbal Levi via Lib-Ext, <
> lib-ext_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/22838.php
>>
>