This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 30.4 [locale.categories] Status: NAD Submitter: P.J. Plauger Opened: 2005-06-20 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [locale.categories].
View all issues with NAD status.
Discussion:
a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table 51" to refer to the facet *objects* associated with a locale. And we almost certainly mean just those associated with the default or "C" locale. Otherwise, you can't switch to a locale that enforces a different mapping between narrow and wide characters, or that defines additional uppercase characters.
b) 22.2.1.5 para. 3 (codecvt) has the same issues.
c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of a homing sequence for the basic character set, which might very well need one.
d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping between wide and narrow characters be taken as one-for-one.
e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as I can tell. The muddle is, as before, calling Table 51 a list of instantiations. But the constraint it applies seems to me to cover *all* defined uses of num_get/put, so why bother to say so?
f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations return '.' or L'.'.) Presumably this means "as appropriate for the character type. But given the vague definition of "required" earlier, this overrules *any* change of decimal point for non "C" locales. Surely we don't want to do that.
g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations return ',' or L','.) As above, this probably means "as appropriate for the character type. But this overrules the "C" locale, which requires *no* character ('\0') for the thousands separator. Even if we agree that we don't mean to block changes in decimal point or thousands separator, we should also eliminate this clear incompatibility with C.
h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations return the empty string, indicating no grouping." Same considerations as for do_decimal_point.
i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table 51". Same bad jargon.
j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required in Table 51". Same bad jargon.
k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous as num_get/put.
l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous as num_get/put.
m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required in Table 51 ... return an object of type pattern initialized to {symbol, sign, none, value}." This once again *overrides* the "C" locale, as well as any other locale."
3) We constrain the use_facet calls that can be made by num_get/put, so why don't we do the same for money_get/put? Or for any of the other facets, for that matter?
4) As an almost aside, we spell out when a facet needs to use the ctype facet, but several also need to use a codecvt facet and we don't say so.
[ Berlin: Bill to provide wording. ]
[ 2009-07 Frankfurt ]
No objection to NAD.
Move to NAD.
Proposed resolution: