Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LWG4044 Confusing requirements for std::print on POSIX platforms #1811

Open
tahonermann opened this issue Mar 9, 2024 · 1 comment
Open
Labels
LWG Library

Comments

@tahonermann
Copy link
Collaborator

https://cplusplus.github.io/LWG/issue4044

@tahonermann tahonermann added the SG16 Text processing label Mar 9, 2024
@tahonermann
Copy link
Collaborator Author

SG16 discussed this issue during its 2024-02-21 meeting. The following polls were taken:

  • Poll 2: Approve the LWG 4044 proposed resolution with the wording about diagnosing invalid code units removed.
    • Attendees: 9
    • No objection to unanimous consent.

SG16 favors removing the following text (both occurrences) from the proposed wording. This is motivated by a lack of understanding regarding what it means to diagnose such invalid code unit sequences given that the input is likely provided at run-time.

If invoking the native Unicode API does not require transcoding, implementations are encouraged to diagnose invalid code units.

Some concern was expressed regarding how the current wording is structured. At present, the wording leads with a Windows centric perspective; if the stream refers to a terminal ... use the native Unicode API ... otherwise write code units to the stream. It might be an improvement to structure the wording such that use of the native Unicode API is presented as a fallback for implementations that require its use when writing directly to the stream is not sufficient to produce desired results. In other words, the wording should permit direct writing to the stream even when the stream is directed to a terminal and a native Unicode API is available when the implementation has reason to believe that doing so will produce the correct results. For example, Microsoft's HoloLens has a Windows based operating system, but it only supports use of UTF-8 as the system code page and therefore would not require the native Unicode API bypass; implementations for it could avoid the overhead of checking to see if the stream is directed to a console.

SG16 review is complete and this now rests solely in LWG's capable hands.

@tahonermann tahonermann added LWG Library and removed SG16 Text processing labels Mar 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LWG Library
Projects
Status: Tentatively Ready
Development

No branches or pull requests

1 participant