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.

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_at_[hidden]> wrote:
>
>
>
> On Sun, 31 Mar 2024 at 10:42, David Armour via Std-Proposals
> <std-proposals_at_[hidden]> 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.
>