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

[Zachary Turner via llvm-dev]

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>