I disagree. If you read the whole section, any reference to string is related to the "output".



On 31/3/2024 20:05, Jonathan Wakely wrote:


On Sun, 31 Mar 2024, 12:54 David Armour, <dave.armour@gmail.com> wrote:
I read this wording in the C++20 standard in section "20.20.2.2 Standard format specifiers" under point 10 :

"For the purposes of width computation, a string is assumed to be in a locale-independent, implementation-
defined encoding. Implementations should use a Unicode encoding on platforms capable of displaying Unicode
text in a terminal.
"

Seems pretty explicit. Width computation does not include locale and is ultimately implementation defined.

That's talking about formatting a string. You're formatting a floating-point number.

That paragraph is not talking about the output of format.



I agree it would seem obvious to have std::format follow imbue() when it comes to locales, but it appears not to be the case.

I am asking that the standard to become specific on this point.

I have already asked Microsoft to modify their compiler behaviour but I would prefer to have the standard clearly back it up.



On 31/3/2024 17:58, Jonathan Wakely wrote:


On Sun, 31 Mar 2024 at 10:55, Jonathan Wakely <cxx@kayari.org> wrote:


On Sun, 31 Mar 2024 at 10:42, David Armour via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
I encountered an issue using std::format to format numbers which I
wanted to have a custom comma thousand separator in the display.

When using the customised locale with MSVC I discovered the added commas
pushed the formatted number to the right making the number no longer
conform to the width specifier.

I tested the same code with GCC and found std::format() to conform
correctly.

I also tested both MSVC and GCC using std::cout.imbue() to make the
stream format the numbers to my custom locale. In this instance it
worked correctly on both compilers.

I tried to find some info about this problem and it seems that for
streams, the standard requires the use of std::setw() to include the
custom locale but for std::format it is left to the compiler implementers.

Why did you conclude that?

It seems obvious to me that any digit separators inserted for a locale-specific form should be included in the estimated field width.

"The estimated field width is the number of field width units that are required for the formatted sequence of characters produced for a format argument independent of the effects of the width option."




I would suggest that the standard forces the same requirement to manage
the custom locale in the width specifier for std::format as well as for
imbue() on streams.

I think it already requires the behaviour you expect. If MSVC doesn't count digit separators in the estimated field width, that seems like a bug.

 

A code sample that reproduces the problem is found below. As mentioned,
this needs to be compiled on MSVC to see the problem. I have not tested
any other compilers to see if they have the same behaviour as MSVC.

For your example code, LLVM's libc++ produces the same output as GCC.