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

[Zachary Turner via llvm-dev]

Will leave this up until this Friday before committing unless there are
further blockers.

On Tue, Nov 8, 2016 at 11:27 AM Zachary Turner <zturner at google.com> wrote:

> This is now done in the latest diff.  Thanks for the suggestion.
>
> On Mon, Nov 7, 2016 at 10:45 PM Chris Lattner <clattner at apple.com> wrote:
>
> On Nov 7, 2016, at 2:58 PM, Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> 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).
>
>
> I haven’t looked at your most recent patch to see if you have already done
> this, but it would be great to add a section about this new API to
> "Important and useful LLVM APIs” in
> http://llvm.org/docs/ProgrammersManual.html.
>
> -Chris
>
>
> 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.
>
> _______________________________________________
>
>
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161108/658fd8fd/attachment.html>