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

[Zachary Turner via llvm-dev]

FWIW, if you're only ever formatting numbers and strings (which I agree is
likely a majority of use cases), the syntax should be very easy to
remember.  Most of the time you don't need to specify anything other than
the placeholder index.  In that respect I expect it to catch on very
quickly as there's really nothing to remember.

Only if you want to customize the behavior will you maybe have to look up
the syntax, and in that case you would have to do something equally funky
with printf (such as not using it and writing 4 lines of streaming stuff to
an ostream instead).

On Mon, Nov 7, 2016 at 2:47 PM Justin Bogner <mail at justinbogner.com> wrote:

> James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes:
> >> 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. :)
>
> FWIW, I'm also not entirely sold that we need a complex formatting
> language here. The printf modifiers are easy to remember and are good
> enough 90% of the time, whereas with something like this I feel like I'd
> need to look up the syntax every time I used it.
>
> Like James though, I'm fine with conceding to the majority on this one.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161107/de5dde0d/attachment.html>