On Wed, Sep 11, 2019 at 3:34 PM Victor Zverovich <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.

–Arthur