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_[hidden] <mailto:arthur.j.odwyer_at_[hidden]>> wrote:
>
> On Wed, Sep 11, 2019 at 3:34 PM Victor Zverovich
> <victor.zverovich_at_[hidden] <mailto:victor.zverovich_at_[hidden]>>
> 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.