On Wed, 11 Sep 2019 at 22:05, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
On Wed, Sep 11, 2019 at 3:34 PM Victor Zverovich <victor.zverovich@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).

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

SG16 Unicode mailing list