[SG16-Unicode] [isocpp-lib] New issue: Are std::format field widths code units, code points, or something else?

Tom Honermann tom at honermann.net
Wed Sep 11 22:34:53 CEST 2019


On 9/11/19 4:28 PM, Corentin Jabot wrote:
>
>
> On Wed, 11 Sep 2019 at 22:05, Arthur O'Dwyer 
> <arthur.j.odwyer at gmail.com <mailto:arthur.j.odwyer at gmail.com>> wrote:
>
>     On Wed, Sep 11, 2019 at 3:34 PM Victor Zverovich
>     <victor.zverovich at gmail.com <mailto:victor.zverovich at gmail.com>>
>     wrote:
>
>         To the best of my knowledge the main use case for width is to
>         align the text when viewed in a terminal or an editor with a
>         monospace font. The second use case is padding the output with
>         '\0', space, or some other character to satisfy some width
>         requirements. It is somewhat limited in addressing the first
>         use case because, as pointed out by Tom, it's hard to solve
>         this problem in general (but it's possibly to have decent
>         approximations), but it works if you restrict your inputs
>         which is what often happens in practice.
>
>         > If no vendor feels that their customers would benefit from a
>         field-width specifier, then there simply won't be any
>         implementation of field-width, and therefore there will be
>         nothing that needs standardizing.
>
>         That is the worst possible option in my opinion because it
>         will create a portability nightmare similar to the one that
>         currently exists with printf extensions.
>
>
>     The current system of printf extensions has been driven by user
>     demand.  Users have use-cases that demand those extensions.
>     - Internationalization of user-visible messages often demands
>     POSIX's positional-argument extension (e.g. "%2$s %1$s").
>     - Convenience often demands GNU's custom-object-type extension
>     (e.g. "%W" for printing Widgets
>     <https://www.gnu.org/software/libc/manual/html_node/Printf-Extension-Example.html>).
>
>     I don't think any vendor will go out of their way to implement a
>     vendor-specific field-width extension without any demand for it.
>     So, in the absence of user demand in the form of use-cases, your
>     "portability nightmare" scenario won't ever materialize.
>
>     The SG16 Unicode group might even end up using "Why does <format>
>     not support field widths?" as a teachable example, similar to how
>     we use "Why does vector not support push_front()?" as a teachable
>     example.
>
>
> Not unreasonable to postpone that feature imo

I disagree as that would harm migration from printf and iostreams to 
std::format.  I don't think there is any controversy regarding use of 
field widths for numeric values.  And we have clear precedent in both 
printf and iostreams regarding how field widths are measured that I 
believe will strongly influence programmer expectations.

Tom.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/unicode/attachments/20190911/2934a110/attachment-0001.html 


More information about the Unicode mailing list