sg16-unicode / sg16

SG16 overview and general information
45 stars 5 forks source link

Publish an SG16 library design guidelines paper #53

Open tahonermann opened 4 years ago

tahonermann commented 4 years ago

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 commented 4 years ago

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

tahonermann commented 4 years ago

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 commented 4 years ago

(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?