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

Zachary Turner via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 12 07:12:07 PDT 2016


Ahh, UDLs also wouldn't permit non literal format strings, which is a deal
breaker imo
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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/e569881d/attachment.html>


More information about the llvm-dev mailing list