Hi Corentin,
Thank you very much for bringing this up!
I think that it makes logical sense to expect the ‘fill character’ to be a complete grapheme cluster. This makes sense – only graphemes have any defined width.
Allowing the fill character to be a codeunit would be nonsensical.
How difficult would it be to say that filling should be performed with a grapheme cluster, but filling with non-grapheme-cluster single codepoints is conditionally supported? It would permit the naïve implementation (and be backwards compatible)
but would allow implementations to DTRT in the future…
Peter
From: SG16 <sg16-bounces@lists.isocpp.org>
On Behalf Of Corentin via SG16
Sent: 09 August 2021 16:30
To: SG16 <sg16@lists.isocpp.org>; Victor Zverovich <victor.zverovich@gmail.com>
Cc: Corentin <corentin.jabot@gmail.com>
Subject: [SG16] LWG3576 - Clarifying fill character in std::format
EXTERNAL MAIL
Hello,
I wanted to bring this new LWG issue to your attention.
The author asks whether the fill character of std::format is
This might be an abi breaking thing, and implementation disagrees already apparently.
My gut feeling is that it needs to at least be a codepoint.
I do not know if there are any concerns with allowing a grapheme in terms of implementation or performance. There is definitively some motivation, especially for non-nfc format strings.
This sort of issue illustrates my point that using the term character in the standard can be problematic!
Thanks,
Have a great week,
Corentin