<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 9/11/19 4:28 PM, Corentin Jabot
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+Om+ShACM6Rm3ik5Cc_CTijGnHiGkBZphX52Du4-UGiBBVwhA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 11 Sep 2019 at
22:05, Arthur O'Dwyer <<a
href="mailto:arthur.j.odwyer@gmail.com"
moz-do-not-send="true">arthur.j.odwyer@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr">On Wed, Sep 11, 2019 at 3:34 PM Victor
Zverovich <<a
href="mailto:victor.zverovich@gmail.com"
target="_blank" moz-do-not-send="true">victor.zverovich@gmail.com</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>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.<br>
</div>
<div><br>
</div>
<div>> 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.</div>
<div><br>
</div>
<div>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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>The current system of printf extensions has been
driven by user demand. Users have use-cases that
demand those extensions.</div>
<div>- Internationalization of user-visible messages
often demands POSIX's positional-argument extension
(e.g. "%2$s %1$s").</div>
<div>- Convenience often demands GNU's
custom-object-type extension (e.g. <a
href="https://www.gnu.org/software/libc/manual/html_node/Printf-Extension-Example.html"
target="_blank" moz-do-not-send="true">"%W" for
printing Widgets</a>).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Not unreasonable to postpone that feature imo</div>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>Tom.<br>
</p>
</body>
</html>