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

[Zachary Turner via llvm-dev]

On Wed, Oct 12, 2016 at 12:40 PM Mehdi Amini <mehdi.amini at apple.com> wrote:

> On Oct 12, 2016, at 12:35 PM, Zachary Turner <zturner at google.com> wrote:
>
> You get compile time checking automatically when we can use c++14 though.
> If you use it with a string literal, you'll get compile time checking,
> otherwise you won’t.
>
>
> I understand that, but that doesn’t really address my concerns.
>
>
> Here's a different example though. Suppose you're writing a tool which
> prints formatted output, and the field width is specified by the user.
>
>
>
> Now you NEED to build the format string at runtime, there's no other way
>
>
> Maybe the problem is using a string to format this in the first place.
>
> For example, you could wrap the object you want to print with an adaptor
> in charge of padding to the right till you reach the column width.
>
> format(“{0}”, rPad(col_width, my_object));
>

FWIW I do think that literal format strings will handle 90% or more of
uses.  I just don't see the benefit of needlessly banning the other cases.
Because all that's going to happen is someone is going to resort to using
snprintf etc, which is exactly the problem I'm trying to solve.  It's
literally no extra effort to support runtime format strings, and it makes
the library more flexible as a result.

I'm willing to start with UDLs only because I think it will get us quite
far, but as soon as I need to pass a format string through an intermediate
function or something like that, I will probably check in the 3 extra lines
of code to add a const char* overload format function.

FWIW, there's no easy way to add compile time checking of format strings
until C++14, regardless of whether use UDLs or not.  So that doesn't change
either way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/40637f49/attachment.html>