<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 2, 2016 at 3:54 PM, Zachary Turner via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><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">* UDL Syntax is removed in the latest version of the <a href="https://reviews.llvm.org/D25587" target="_blank">patch</a>.  <div>* Name changed to `formatv` since `format_string` is too much to type.</div><div>*<span class="gmail-m_3572889092807705444inbox-inbox-Apple-converted-space"> Added conversion operators for `std::string` and `llvm::SmallString`.</span></div><div><br></div><div>I had some feedback offline (not on this thread, unfortunately) that it might be worth using a printf style syntax instead of this Python-esque syntax.  FTR, I actually somewhat object to this, for a couple of reasons:</div><div><br></div><div>1) It makes back-reference syntax ugly.   "{0} {1} {0}" is much clearer to me than "%0$ %1$ %0$".  The latter syntax is also not a very well known feature of printf and so unlikely to be used by people with a printf-style implementation, whereas it's un-missable with the python-style syntax</div></div></blockquote><div><br></div><div>Don't forget the trailing "s" (or whatever) -- "%0$s %1$s %0$s". (The possibility to forget the trailing letter is a downside of the printf syntax, certainly.)</div><div><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>2) I don't see why we should need to specify the type of the argument with %d if the compiler knows it's an integer.  Even if the we can add compile-time checking to make it error, it seems unnecessary to even encounter this situation in the first place.  I believe the compiler should simply format what you give it.</div></div></blockquote><div><br></div><div>Well, it would seem fine to me if "%s" converted integers/floats/etc to a string for you as well. What %d really gives you is ability to specify the numeric formatting options instead of the string formatting options.</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>3) One of the most useful aspects of the current approach is the ability to plug in custom formatters for application specific data types.  This is not straightforward with a printf-style syntax.  </div></div></blockquote><div><br></div><div>It is true, printf style formatting doesn't allow something like this:</div><div><span style="font-size:12.8px">  formatv("{0:DD/MM/YYYY hh:mm:ss}", std::chrono::system_clock::</span><wbr style="font-size:12.8px"><span style="font-size:12.8px">now());</span></div><div><br></div><div>On the other hand, what printf does have is a single description of what formatting strings are valid. With your proposed system, you need to know what type the argument is, in order to know what the D in "{0:D}" is going to mean. IMO, that the printf syntax is both well-known and NOT extensible seems an advantage to me, not a disadvantage.</div><div><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>You might be able to hook up a template-specialization like mechanic to the processing of %s (similar to my current approach), but it's not obvious how you proceed from there to get custom format strings for individual types.  For example, a formatter which can print a TimeSpan in different units depending on style options you pass in.  This is especially useful when trying to print ranges where you often want to be able to specify a different separator, or control the formatting of the underlying type.  (e.g. it's not clear how you would elegantly format a range of integers in hex using this style of approach).<br></div></div></blockquote><div><br></div><div>It is entirely unclear to me that putting everything in a format string:</div><div>  formatv("Here's a range: {0:$[ + ]@[x]}", range);<br></div><div>is better than composing functions with usual function-call syntax, e.g. something like this:<br></div><div>  format("Here's a range: %s", Join(range, " + ", Formatter("%x")));<br></div><div><br></div><div>I think that's the meat of the disagreement: I'd prefer to just see a safe printf-replacement; something that's able to basically drop-in replace C printf, nothing super fancy. I don't see the justification for being able to specify everything you'd ever want to be able to do directly in a complex format string language.</div><div><br></div><div>On the other hand, you see value in being able to specify the entirety of the output in the format string, and aren't concerned about the syntax being new and complicated.</div><div><br></div><div>That said -- it doesn't appear that my point of view is widely held, and that's fine -- this is a matter of opinion, not right or wrong. So, continue on. :)</div></div></div></div>