Section: 22.214.171.124.2 [facet.num.get.virtuals] Status: CD1 Submitter: Martin Sebor Opened: 2002-03-12 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [facet.num.get.virtuals].
View all issues with CD1 status.
I don't think thousands_sep is being treated correctly after decimal_point has been seen. Since grouping applies only to the integral part of the number, the first such occurrence should, IMO, terminate Stage 2. (If it does not terminate it, then 126.96.36.199.2, p12 and 188.8.131.52.2, p3 need to explain how thousands_sep is to be interpreted in the fractional part of a number.)
The easiest change I can think of that resolves this issue would be something like below.
Change the first sentence of 184.108.40.206.2, p9 from
If discard is true then the position of the character is remembered, but the character is otherwise ignored. If it is not discarded, then a check is made to determine if c is allowed as the next character of an input field of the conversion specifier returned by stage 1. If so it is accumulated.
If discard is true, then if '.' has not yet been accumulated, then the position of the character is remembered, but the character is otherwise ignored. Otherwise, if '.' has already been accumulated, the character is discarded and Stage 2 terminates. ...
We believe this reflects the intent of the Standard. Thousands sep characters after the decimal point are not useful in any locale. Some formatting conventions do group digits that follow the decimal point, but they usually introduce a different grouping character instead of reusing the thousand sep character. If we want to add support for such conventions, we need to do so explicitly.