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

I don't object to compile time checking *as long as it doesn't severely
detract from brevity*.  At the same time, I do object to *preventing*
runtime format strings.

When we have C++14, we can make every member of StringRef constexpr, and at
that point we will get compile time checking mostly "for free" without
preventing runtime format strings.  For example, given a constexpr-aware
implementation of StringRef, if you were to write: os.format("literal
format", a, b, c) you would get all the compile time checking, such as
ensuring that the number of arguments matches the highest index in the
format string, and ensuring there are enough arguments for every
placeholder.  But if you wrote os.format(s, a, b, c) you would still get
runtime checking of the format strings.

As long as the runtime implementation doesn't exhibit UB when things
don't
match up, and it kindly asserts to warn you of the problem in the test
suite, support runtime format strings can be very helpful.  For example, it
could allow you to wrap a call to format in some other function, like:

template<typename... Ts>
void wrap_format(const char *Format, Ts &&... Args) {
   dbgs().format(Format, ConvertArg(Args)...);
}

On Wed, Oct 12, 2016 at 11:24 AM Mehdi Amini <mehdi.amini at apple.com>
wrote:
> On Oct 12, 2016, at 7:12 AM, Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Ahh, UDLs also wouldn't permit non literal format strings, which is a
deal
> breaker imo
>
>
> Why?
> Somehow the goal pursued by Pavel (which you didn’t object per-se) is to
> provide *compile* time checking.
> This imply that you cannot decouple the construction of the format and the
> argument list.
>
> —
> Mehdi
>
> On Wed, Oct 12, 2016 at 7:03 AM Zachary Turner <zturner at
google.com> wrote:
>
> I'm not sure that would work well. The implementation relies on being
able
> to index into the parameter pack. How would you do that if each parameter
> is streamed in?
>
> "{0} {1}"_fs(1, 2)
>
> Could perhaps work, but it looks a little strange to me.
>
> Fwiw i agree format_string is long. Ideally it would be called format, but
> that's taken.
>
> Another option is os.format("{0}", 7), and have
format_string("{0}", 7)
> return a std::string.
> On Wed, Oct 12, 2016 at 6:43 AM Aaron Ballman <aaron at
aaronballman.com>
> wrote:
>
> >> 1. os << format_string("Test");   // writes
"test"
> >> 2. os << format_string("{0}", 7);  // writes
"7"
> >
> >
> > The "<< format_string(..." is ... really verbose for
me. It also makes me
> > strongly feel like this produces a string rather than a streamable
> entity.
>
> I wonder if we could use UDLs instead?
>
> os << "Test" << "{0}"_fs << 7;
>
> ~Aaron
>
> >
> > I'm not a huge fan of streaming, but if we want to go this route,
I'd
> very
> > much like to keep the syntax short and sweet. "format" is
pretty great
> for
> > that. If this is going to fully subsume its use cases, can we
eventually
> get
> > that to be the name?
> >
> > (While I don't like streaming, I'm not trying to fight that
battle
> here...)
> >
> > Also, you should probably look at what is quickly becoming a popular
C++
> > library in this space: https://github.com/fmtlib/fmt
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> _______________________________________________
> 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/20161012/596b57d2/attachment.html>

> On Oct 12, 2016, at 11:38 AM, Zachary Turner <zturner at google.com>
wrote:
> 
> I don't object to compile time checking *as long as it doesn't
severely detract from brevity*.
> At the same time, I do object to *preventing* runtime format strings.
You haven’t answered: why?

— 
Mehdi

> 
> When we have C++14, we can make every member of StringRef constexpr, and at
that point we will get compile time checking mostly "for free" without
preventing runtime format strings.  For example, given a constexpr-aware
implementation of StringRef, if you were to write: os.format("literal
format", a, b, c) you would get all the compile time checking, such as
ensuring that the number of arguments matches the highest index in the format
string, and ensuring there are enough arguments for every placeholder.  But if
you wrote os.format(s, a, b, c) you would still get runtime checking of the
format strings.
> 
> As long as the runtime implementation doesn't exhibit UB when things
don't match up, and it kindly asserts to warn you of the problem in the test
suite, support runtime format strings can be very helpful.  For example, it
could allow you to wrap a call to format in some other function, like:
> 
> template<typename... Ts>
> void wrap_format(const char *Format, Ts &&... Args) {
>    dbgs().format(Format, ConvertArg(Args)...);
> }
> 
> On Wed, Oct 12, 2016 at 11:24 AM Mehdi Amini <mehdi.amini at apple.com
<mailto:mehdi.amini at apple.com>> wrote:
>> On Oct 12, 2016, at 7:12 AM, Zachary Turner via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> Ahh, UDLs also wouldn't permit non literal format strings, which is
a deal breaker imo
> 
> Why?
> Somehow the goal pursued by Pavel (which you didn’t object per-se) is to
provide *compile* time checking.
> This imply that you cannot decouple the construction of the format and the
argument list.
> 
> — 
> Mehdi
> 
>> On Wed, Oct 12, 2016 at 7:03 AM Zachary Turner <zturner at
google.com <mailto:zturner at google.com>> wrote:
>> I'm not sure that would work well. The implementation relies on
being able to index into the parameter pack. How would you do that if each
parameter is streamed in?
>> 
>> "{0} {1}"_fs(1, 2)
>> 
>> Could perhaps work, but it looks a little strange to me.
>> 
>> Fwiw i agree format_string is long. Ideally it would be called format,
but that's taken.
>> 
>> Another option is os.format("{0}", 7), and have
format_string("{0}", 7) return a std::string.
>> On Wed, Oct 12, 2016 at 6:43 AM Aaron Ballman <aaron at
aaronballman.com <mailto:aaron at aaronballman.com>> wrote:
>> >> 1. os << format_string("Test");   // writes
"test"
>> >> 2. os << format_string("{0}", 7);  // writes
"7"
>> >
>> >
>> > The "<< format_string(..." is ... really verbose
for me. It also makes me
>> > strongly feel like this produces a string rather than a streamable
entity.
>> 
>> I wonder if we could use UDLs instead?
>> 
>> os << "Test" << "{0}"_fs << 7;
>> 
>> ~Aaron
>> 
>> >
>> > I'm not a huge fan of streaming, but if we want to go this
route, I'd very
>> > much like to keep the syntax short and sweet. "format"
is pretty great for
>> > that. If this is going to fully subsume its use cases, can we
eventually get
>> > that to be the name?
>> >
>> > (While I don't like streaming, I'm not trying to fight
that battle here...)
>> >
>> > Also, you should probably look at what is quickly becoming a
popular C++
>> > library in this space: https://github.com/fmtlib/fmt
<https://github.com/fmtlib/fmt>
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> >
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/20161012/4f4ea6b0/attachment.html>

I thought I did.  :)  Passing format strings between functions is very
useful.  For example, imagine wanting to write a function like
printRange(const char *Fmt, std::vector<int> Items);

This isn't possible if your format string MUST be a string literal and is
very useful.

Equally importantly, I don't see a good reason to disallow runtime format
strings.

On Wed, Oct 12, 2016 at 11:59 AM Mehdi Amini <mehdi.amini at apple.com>
wrote:
> On Oct 12, 2016, at 11:38 AM, Zachary Turner <zturner at google.com>
wrote:
>
> I don't object to compile time checking *as long as it doesn't
severely
> detract from brevity*.
>
>
>
> At the same time, I do object to *preventing* runtime format strings.
>
>
> You haven’t answered: why?
>
> —
> Mehdi
>
>
>
> When we have C++14, we can make every member of StringRef constexpr, and
> at that point we will get compile time checking mostly "for free"
without
> preventing runtime format strings.  For example, given a constexpr-aware
> implementation of StringRef, if you were to write: os.format("literal
> format", a, b, c) you would get all the compile time checking, such as
> ensuring that the number of arguments matches the highest index in the
> format string, and ensuring there are enough arguments for every
> placeholder.  But if you wrote os.format(s, a, b, c) you would still get
> runtime checking of the format strings.
>
> As long as the runtime implementation doesn't exhibit UB when things
don't
> match up, and it kindly asserts to warn you of the problem in the test
> suite, support runtime format strings can be very helpful.  For example, it
> could allow you to wrap a call to format in some other function, like:
>
> template<typename... Ts>
> void wrap_format(const char *Format, Ts &&... Args) {
>    dbgs().format(Format, ConvertArg(Args)...);
> }
>
> On Wed, Oct 12, 2016 at 11:24 AM Mehdi Amini <mehdi.amini at
apple.com>
> wrote:
>
> On Oct 12, 2016, at 7:12 AM, Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Ahh, UDLs also wouldn't permit non literal format strings, which is a
deal
> breaker imo
>
>
> Why?
> Somehow the goal pursued by Pavel (which you didn’t object per-se) is to
> provide *compile* time checking.
> This imply that you cannot decouple the construction of the format and the
> argument list.
>
> —
> Mehdi
>
> On Wed, Oct 12, 2016 at 7:03 AM Zachary Turner <zturner at
google.com> wrote:
>
> I'm not sure that would work well. The implementation relies on being
able
> to index into the parameter pack. How would you do that if each parameter
> is streamed in?
>
> "{0} {1}"_fs(1, 2)
>
> Could perhaps work, but it looks a little strange to me.
>
> Fwiw i agree format_string is long. Ideally it would be called format, but
> that's taken.
>
> Another option is os.format("{0}", 7), and have
format_string("{0}", 7)
> return a std::string.
> On Wed, Oct 12, 2016 at 6:43 AM Aaron Ballman <aaron at
aaronballman.com>
> wrote:
>
> >> 1. os << format_string("Test");   // writes
"test"
> >> 2. os << format_string("{0}", 7);  // writes
"7"
> >
> >
> > The "<< format_string(..." is ... really verbose for
me. It also makes me
> > strongly feel like this produces a string rather than a streamable
> entity.
>
> I wonder if we could use UDLs instead?
>
> os << "Test" << "{0}"_fs << 7;
>
> ~Aaron
>
> >
> > I'm not a huge fan of streaming, but if we want to go this route,
I'd
> very
> > much like to keep the syntax short and sweet. "format" is
pretty great
> for
> > that. If this is going to fully subsume its use cases, can we
eventually
> get
> > that to be the name?
> >
> > (While I don't like streaming, I'm not trying to fight that
battle
> here...)
> >
> > Also, you should probably look at what is quickly becoming a popular
C++
> > library in this space: https://github.com/fmtlib/fmt
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> _______________________________________________
> 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/20161012/852a9dbd/attachment.html>