[llvm-dev] RFC: General purpose type-safe formatting library

[James Y Knight via llvm-dev]

On Wed, Nov 2, 2016 at 3:54 PM, Zachary Turner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> * UDL Syntax is removed in the latest version of the patch
> <https://reviews.llvm.org/D25587>.
> * Name changed to `formatv` since `format_string` is too much to type.
> * Added conversion operators for `std::string` and `llvm::SmallString`.
>
> 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:
>
> 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
>

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.)

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.
>

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.


> 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.
>

It is true, printf style formatting doesn't allow something like this:
  formatv("{0:DD/MM/YYYY hh:mm:ss}", std::chrono::system_clock::now());

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.

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).
>

It is entirely unclear to me that putting everything in a format string:
  formatv("Here's a range: {0:$[ + ]@[x]}", range);
is better than composing functions with usual function-call syntax, e.g.
something like this:
  format("Here's a range: %s", Join(range, " + ", Formatter("%x")));

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.

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.

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. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161107/e3322b64/attachment.html>