llvm dev - Nov 2016 - RFC: General purpose type-safe formatting library

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.

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>

> 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
<http://llvm.org/docs/ProgrammersManual.html>.

-Chris
> 
> On Mon, Nov 7, 2016 at 2:47 PM Justin Bogner <mail at justinbogner.com
<mailto:mail at justinbogner.com>> wrote:
> James Y Knight via llvm-dev <llvm-dev at lists.llvm.org
<mailto: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/20161107/ded5ee3d/attachment.html>