This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

3674. Removal of requirement for locale names for construction of locales not explained

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(i) 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 no LC_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.

  1. Modify 28.3.3.1.4 [locale.members] as indicated:

    string name() const;

    -5- Returns: The name of *this, if it has one; otherwise, the string "*".

    -?- 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 setlocale(LC_ALL, name().c_str()) returns a non-null pointer. [Note 1: With such a name locale(name().c_str()) succeeds and does not throw runtime_error. — end note]