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

Publish an SG16 library design guidelines paper #53

Open
tahonermann opened this issue Nov 25, 2019 · 3 comments
Open

Publish an SG16 library design guidelines paper #53

tahonermann opened this issue Nov 25, 2019 · 3 comments
Assignees
Labels
paper needed A paper proposing a specific solution is needed

Comments

@tahonermann
Copy link
Member

During the SG16 meeting held July 31st, 2019, we discussed guidelines for when to add function overloads for each of char, wchar_t, char8_t, char16_t, and char32_t. It would be useful to capture these guidelines in an SG16 library design guidelines paper. There are probably a number of other guidelines that we can come up with as well.

@tahonermann
Copy link
Member Author

At the SG16 meeting held November 20th, 2019, Zach expressed interest in working on this.

@tahonermann tahonermann added the paper needed A paper proposing a specific solution is needed label Nov 25, 2019
@tahonermann
Copy link
Member Author

In Belfast, discussion of P1935 explored whether locale concerns should be handled implicitly (as happens with iostreams today) or explicitly (as std::format requires). This would be a good topic to address in the library design guidelines paper.

@ThePhD
Copy link
Collaborator

ThePhD commented Feb 3, 2020

(The following is all an opinion.)

For (w)char(8/16/32_t) Overloads

They should be added wherever string literals would be a common interface point. For example, path_view contains much of this churn solely because it sits on the interface where string literals of all kinds will be used. Specific code unit types (e.g., char32_t) may be selectively used where applicable.

For Locale

Locale -- our current iteration, and whatever comes in the future -- should always be opt-in, and never opt-out. The only time it should ever be present is for interfaces reasonably expected to be engaged for the purposes of user-facing presentation and user-facing text classification purposes. By default it should use a pre-picked, unchanging set of "Machine" (generally what's packed in the Default Unicode Collation Element Table (DUCET) if collation is involved). No idea what goes in "Machine", but that's why we're here, no?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
paper needed A paper proposing a specific solution is needed
Development

No branches or pull requests

3 participants