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_at_[hidden]> 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_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.
>>
>