<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 &lt;<a
              href="mailto:arthur.j.odwyer@gmail.com"
              moz-do-not-send="true">arthur.j.odwyer@gmail.com</a>&gt;
            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 &lt;<a
                  href="mailto:victor.zverovich@gmail.com"
                  target="_blank" moz-do-not-send="true">victor.zverovich@gmail.com</a>&gt;
                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>&gt; 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 &lt;format&gt; 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>