> The current system of printf extensions has been driven by user demand.

Yes and AFAICS that model failed spectacularly. For example, the POSIX
extension for positional arguments can't be used portably. This was one of
the issues addressed by the fmt library.

Removing width or making its semantics implementation-defined would be a
huge regression compared to both printf and iostreams. I'd strongly advise
against it.

With Tom's proposed resolution we can have a reasonable, efficient, and
deterministic behavior now and a good path towards addressing more
complicated cases both in Unicode overloads and char/wchar_t overloads
later.

- Victor

On Wed, Sep 11, 2019 at 1:05 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:

> 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
>