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

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>

> On Oct 12, 2016, at 8:07 PM, Zachary Turner <zturner at google.com>
wrote:
> 
> On Wed, Oct 12, 2016 at 12:40 PM Mehdi Amini <mehdi.amini at apple.com
<mailto:mehdi.amini at apple.com>> wrote:
>> On Oct 12, 2016, at 12:35 PM, Zachary Turner <zturner at google.com
<mailto: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.
Sorry but you’re totally missing the point. If there is a need for dynamism,
this should be supported, that’s not the question. My point is that generating a
string that will be parsed by a format function can’t be the only solution.
>   It's literally no extra effort to support runtime format strings, and
it makes the library more flexible as a result.
No: it does *not* make it more flexible than a non-string based solution that
have the same functionality.

— 
Mehdi


> 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/20161012/842a4392/attachment.html>

AFAICT this appears to be the first time you've clarified that you're
talking about a situation where the compile-time checking happens using
something other than format strings.  In Pavel's original email, he
suggested compile time checking and you mentioned that I didn't object to
it.  But if you go back and read my response, I said we can do the compile
time checking *of the format strings* using C++14.  So no I didn't object
to it in principle, but I never strayed from the desire to use format
strings.

To respond to your other point, no it doesn't make it more flexible than a
non-string based solution.  But does anyone want a non string-based
solution?  We already have one, it's called raw_ostream.  And STL has
another one in iostreams.  sprintf and llvm::format are not more flexible
than streaming operators either, and yet people still flock to them because
it yields the nicest looking code.  James Knight pointed out earlier that
"any time someone invents a new formatting library, everyone always ends up
using printf anyway".  There's a reason for that, and it's because
printf
is string-based.  That's what people want.

So if we're talking about string-based versus non string-based, then yes,
I'm married to the idea of a string based solution.

That doesn't mean we can't *also* expose the underlying format
functionality via an additional set of non format based functions.  But
string-based formatting is necessary if there is to be any adoption at all.

On Wed, Oct 12, 2016 at 8:19 PM Mehdi Amini <mehdi.amini at apple.com>
wrote:
> On Oct 12, 2016, at 8:07 PM, Zachary Turner <zturner at google.com>
wrote:
>
> 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.
>
>
> Sorry but you’re totally missing the point. If there is a need for
> dynamism, this should be supported, that’s not the question. My point is
> that generating a string that will be parsed by a format function can’t be
> the only solution.
>
>   It's literally no extra effort to support runtime format strings, and
it
> makes the library more flexible as a result.
>
>
> No: it does *not* make it more flexible than a non-string based solution
> that have the same functionality.
>
> —
> Mehdi
>
>
>
> 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/be7c62da/attachment.html>