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.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 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.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]