Section: 28.3.3.1.4 [locale.members] Status: New Submitter: Hubert Tong Opened: 2022-02-12 Last modified: 2022-03-04
Priority: 2
View all other issues in [locale.members].
View all issues with New status.
Discussion:
LWG 2394 removed the only text in the wording that requires that the name of a locale is usable for constructing further locales.
The relevant notes from the wiki appear to make it seem like LWG thought the change was editorial. Perhaps the resolution was motivated by a different defect than the one that led to the change? Namely,explicit locale(const char* std_name);
is said to use "standard C locale names".
There is noLC_MESSAGES in standard C.
Thus, it is a question whether the aforementioned constructor should be able to consume names produced by the
C++ implementation.
See also the use of the name of the C++ locale in locale::global() for use with setlocale.
The following would restore the equivalence of locales that have the same name. It also addresses the
suitability of the name for use with setlocale and the locale(const char*) constructor
as a matter of QoI.
[2022-03-04; Reflector poll]
Set priority to 2 after reflector poll.
Proposed resolution:
This wording is relative to N4901.
Modify 28.3.3.1.4 [locale.members] as indicated:
string name() const;-5- Returns: The name of
-?- Remarks: Two locales have identical names only if their facets have identical virtual function semantics. -?- Recommended practice: The name of a locale that has a name should be such that*this, if it has one; otherwise, the string"*".setlocale(LC_ALL, name().c_str())returns a non-null pointer. [Note 1: With such a namelocale(name().c_str())succeeds and does not throwruntime_error. — end note]