On Wed, 11 Sep 2019 at 22:05, 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.
>

Not unreasonable to postpone that feature imo


>
> –Arthur
> _______________________________________________
> SG16 Unicode mailing list
> Unicode_at_[hidden]
> http://www.open-std.org/mailman/listinfo/unicode
>