<div dir="ltr"><div>&gt; The current system of printf extensions has been driven by user demand.</div><div><br></div><div>Yes and AFAICS that model failed spectacularly. For example, the POSIX extension for positional arguments can&#39;t be used portably. This was one of the issues addressed by the fmt library.</div><div><br></div><div>Removing width or making its semantics implementation-defined would be a huge regression compared to both printf and iostreams. I&#39;d strongly advise against it.</div><div><br></div><div>With Tom&#39;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.<br></div><div><br></div><div>- Victor<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 11, 2019 at 1:05 PM Arthur O&#39;Dwyer &lt;<a href="mailto:arthur.j.odwyer@gmail.com">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">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 &#39;\0&#39;, 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&#39;s hard to solve this problem in general (but it&#39;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&#39;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&#39;s positional-argument extension (e.g. &quot;%2$s %1$s&quot;).</div><div>- Convenience often demands GNU&#39;s custom-object-type extension (e.g. <a href="https://www.gnu.org/software/libc/manual/html_node/Printf-Extension-Example.html" target="_blank">&quot;%W&quot; for printing Widgets</a>).</div><div><br></div><div>I don&#39;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 &quot;portability nightmare&quot; scenario won&#39;t ever materialize.</div><div><br></div><div>The SG16 Unicode group might even end up using &quot;Why does &lt;format&gt; not support field widths?&quot; as a teachable example, similar to how we use &quot;Why does vector not support push_front()?&quot; as a teachable example.</div><div><br></div><div>–Arthur</div></div></div>
</blockquote></div>