<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&#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></div></blockquote><div><br></div><div>Not unreasonable to postpone that feature imo</div><div> </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 class="gmail_quote"><div><br></div><div>–Arthur</div></div></div>
_______________________________________________<br>
SG16 Unicode mailing list<br>
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank">Unicode@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/unicode" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/unicode</a><br>
</blockquote></div></div>