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

On Mon, Oct 31, 2016 at 3:46 PM Zachary Turner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
> Tentatively final version is up here: https://reviews.llvm.org/D25587
>
> It has a verbal LGTM, but I plan to wait a bit longer just in case anyone
> has some additional thoughts.  It's a large patch, but if you're
> interested, one way you can help without doing a full-blown review is to
> look at the large comment blocks in FormatVariadic.h and
> FormatProviders.h.  Here I provide a formal description of the grammar of
> the replacement sequences and format syntax.  So you can look at this
> without looking at the code behind it and see if you have comments just on
> the format language.
>
> Here's a summary of (most) everything contained in this patch:
>
> 1) UDL Syntax for outputting to a stream or converting to a string.
>     outs() << "{0}"_fmt.stream(1)
>     std::string S = "{0}"_fmt.string(1);
>
I continue to have a strong objection to using UDLs for this (or anything
else in LLVM).

I think this feature is poorly known by many programmers. I think it will
produce error messages that are confusing and hard to debug. I think it
will have a significant negative impact on compile time. I also think that
it will exercise substantially less well tested parts of every host
compiler for LLVM and subject us to an increased rate of mysterious host
compiler bugs.

I also think it forces programmers to be aware of a "magical"
construct
that doesn't really fit with the rest of the language.

It isn't that any of these issues in isolation cannot be overcome, it is
that I think the value provided by the UDL specifically is substantially
smaller than the cost.

I would *very strongly* prefer that this is accomplished with "normal"
C++
syntax, and that compile time checking is done with constexpr when
available. I think that will give the overwhelming majority of the benefit
with dramatically lower cost.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161101/9533542d/attachment-0001.html>

Ahh, I must have missed where you voiced that objection earlier. Do you
prefer that UDL syntax be explicitly disallowed, or do you only prefer that
normal c++ syntax be possible? It is currently possible, I just didn't
demonstrate it in the previous message since almost all the feedback i had
seen so far seemed to prefer UDL syntax due to the brevity and similarity
to Python.

I recall you mentioned the verbosity of llvm format as something you would
like to see this improve, so i had assumed you would be happy with UDL
syntax.

compile time checking may not be possible without UDLs unless we wrap the
format string in a macro, which may hurt readability even more. With a UDL
we can get it via the gnu literal operator template though, and the check
can be #ifdef'ed out on any compiler that doesn't support that extension

In any case, both syntaxes are currently supported. Is that acceptable?
On Mon, Oct 31, 2016 at 5:21 PM Chandler Carruth <chandlerc at gmail.com>
wrote:
> On Mon, Oct 31, 2016 at 3:46 PM Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> Tentatively final version is up here: https://reviews.llvm.org/D25587
>
> It has a verbal LGTM, but I plan to wait a bit longer just in case anyone
> has some additional thoughts.  It's a large patch, but if you're
> interested, one way you can help without doing a full-blown review is to
> look at the large comment blocks in FormatVariadic.h and
> FormatProviders.h.  Here I provide a formal description of the grammar of
> the replacement sequences and format syntax.  So you can look at this
> without looking at the code behind it and see if you have comments just on
> the format language.
>
> Here's a summary of (most) everything contained in this patch:
>
> 1) UDL Syntax for outputting to a stream or converting to a string.
>     outs() << "{0}"_fmt.stream(1)
>     std::string S = "{0}"_fmt.string(1);
>
>
> I continue to have a strong objection to using UDLs for this (or anything
> else in LLVM).
>
> I think this feature is poorly known by many programmers. I think it will
> produce error messages that are confusing and hard to debug. I think it
> will have a significant negative impact on compile time. I also think that
> it will exercise substantially less well tested parts of every host
> compiler for LLVM and subject us to an increased rate of mysterious host
> compiler bugs.
>
> I also think it forces programmers to be aware of a "magical"
construct
> that doesn't really fit with the rest of the language.
>
> It isn't that any of these issues in isolation cannot be overcome, it
is
> that I think the value provided by the UDL specifically is substantially
> smaller than the cost.
>
> I would *very strongly* prefer that this is accomplished with
"normal" C++
> syntax, and that compile time checking is done with constexpr when
> available. I think that will give the overwhelming majority of the benefit
> with dramatically lower cost.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161101/ab7459d0/attachment.html>

Another advantage of the UDL syntax is that gnu literal operator templates
are supported by clang today, so we can get compile time checking
immediately rather than having to wait for c++14 (and then suffer an
inferior syntax to boot)
On Mon, Oct 31, 2016 at 5:45 PM Zachary Turner <zturner at google.com>
wrote:
> Ahh, I must have missed where you voiced that objection earlier. Do you
> prefer that UDL syntax be explicitly disallowed, or do you only prefer that
> normal c++ syntax be possible? It is currently possible, I just didn't
> demonstrate it in the previous message since almost all the feedback i had
> seen so far seemed to prefer UDL syntax due to the brevity and similarity
> to Python.
>
> I recall you mentioned the verbosity of llvm format as something you would
> like to see this improve, so i had assumed you would be happy with UDL
> syntax.
>
> compile time checking may not be possible without UDLs unless we wrap the
> format string in a macro, which may hurt readability even more. With a UDL
> we can get it via the gnu literal operator template though, and the check
> can be #ifdef'ed out on any compiler that doesn't support that
extension
>
> In any case, both syntaxes are currently supported. Is that acceptable?
> On Mon, Oct 31, 2016 at 5:21 PM Chandler Carruth <chandlerc at
gmail.com>
> wrote:
>
> On Mon, Oct 31, 2016 at 3:46 PM Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> Tentatively final version is up here: https://reviews.llvm.org/D25587
>
> It has a verbal LGTM, but I plan to wait a bit longer just in case anyone
> has some additional thoughts.  It's a large patch, but if you're
> interested, one way you can help without doing a full-blown review is to
> look at the large comment blocks in FormatVariadic.h and
> FormatProviders.h.  Here I provide a formal description of the grammar of
> the replacement sequences and format syntax.  So you can look at this
> without looking at the code behind it and see if you have comments just on
> the format language.
>
> Here's a summary of (most) everything contained in this patch:
>
> 1) UDL Syntax for outputting to a stream or converting to a string.
>     outs() << "{0}"_fmt.stream(1)
>     std::string S = "{0}"_fmt.string(1);
>
>
> I continue to have a strong objection to using UDLs for this (or anything
> else in LLVM).
>
> I think this feature is poorly known by many programmers. I think it will
> produce error messages that are confusing and hard to debug. I think it
> will have a significant negative impact on compile time. I also think that
> it will exercise substantially less well tested parts of every host
> compiler for LLVM and subject us to an increased rate of mysterious host
> compiler bugs.
>
> I also think it forces programmers to be aware of a "magical"
construct
> that doesn't really fit with the rest of the language.
>
> It isn't that any of these issues in isolation cannot be overcome, it
is
> that I think the value provided by the UDL specifically is substantially
> smaller than the cost.
>
> I would *very strongly* prefer that this is accomplished with
"normal" C++
> syntax, and that compile time checking is done with constexpr when
> available. I think that will give the overwhelming majority of the benefit
> with dramatically lower cost.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161101/f1615f99/attachment.html>

On Mon, Oct 31, 2016 at 5:21 PM, Chandler Carruth via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Mon, Oct 31, 2016 at 3:46 PM Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> Tentatively final version is up here: https://reviews.llvm.org/D25587
>>
>> It has a verbal LGTM, but I plan to wait a bit longer just in case
anyone
>> has some additional thoughts.  It's a large patch, but if
you're
>> interested, one way you can help without doing a full-blown review is
to
>> look at the large comment blocks in FormatVariadic.h and
>> FormatProviders.h.  Here I provide a formal description of the grammar
of
>> the replacement sequences and format syntax.  So you can look at this
>> without looking at the code behind it and see if you have comments just
on
>> the format language.
>>
>> Here's a summary of (most) everything contained in this patch:
>>
>> 1) UDL Syntax for outputting to a stream or converting to a string.
>>     outs() << "{0}"_fmt.stream(1)
>>     std::string S = "{0}"_fmt.string(1);
>>
>
> I continue to have a strong objection to using UDLs for this (or anything
> else in LLVM).
>
> I think this feature is poorly known by many programmers. I think it will
> produce error messages that are confusing and hard to debug. I think it
> will have a significant negative impact on compile time. I also think that
> it will exercise substantially less well tested parts of every host
> compiler for LLVM and subject us to an increased rate of mysterious host
> compiler bugs.
>
> I also think it forces programmers to be aware of a "magical"
construct
> that doesn't really fit with the rest of the language.
>
> It isn't that any of these issues in isolation cannot be overcome, it
is
> that I think the value provided by the UDL specifically is substantially
> smaller than the cost.
>
> I would *very strongly* prefer that this is accomplished with
"normal" C++
> syntax, and that compile time checking is done with constexpr when
> available. I think that will give the overwhelming majority of the benefit
> with dramatically lower cost.
>
+1, the UDL seems a bit too automagical.
`format_string("{0}", 1)` is not that much longer than
`"{0}"_fmt.string(1)`, but significantly less magical.

Simple example: what should I type into a search engine to find the LLVM
doxygen for the UDL? I know to search "llvm format_string" for the
format
string, but just from looking at a use of the UDL syntax it might not be
clear that format_string is even called.

-- Sean Silva

>
> _______________________________________________
> 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/20161031/7dd95b31/attachment.html>

The big problem i see is that to get compile time checking without the UDL
we're going to have to do something like FORMAT_STRING("{0}")
where this is
a macro. It just seems really gross. It is true that it is harder to find
the documentation, but that could be alleviated by putting all of this in
its own namespace like llvm::formatv, then one could search the namespace
On Mon, Oct 31, 2016 at 11:41 PM Sean Silva <chisophugis at gmail.com>
wrote:
> On Mon, Oct 31, 2016 at 5:21 PM, Chandler Carruth via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> On Mon, Oct 31, 2016 at 3:46 PM Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> Tentatively final version is up here: https://reviews.llvm.org/D25587
>
> It has a verbal LGTM, but I plan to wait a bit longer just in case anyone
> has some additional thoughts.  It's a large patch, but if you're
> interested, one way you can help without doing a full-blown review is to
> look at the large comment blocks in FormatVariadic.h and
> FormatProviders.h.  Here I provide a formal description of the grammar of
> the replacement sequences and format syntax.  So you can look at this
> without looking at the code behind it and see if you have comments just on
> the format language.
>
> Here's a summary of (most) everything contained in this patch:
>
> 1) UDL Syntax for outputting to a stream or converting to a string.
>     outs() << "{0}"_fmt.stream(1)
>     std::string S = "{0}"_fmt.string(1);
>
>
> I continue to have a strong objection to using UDLs for this (or anything
> else in LLVM).
>
> I think this feature is poorly known by many programmers. I think it will
> produce error messages that are confusing and hard to debug. I think it
> will have a significant negative impact on compile time. I also think that
> it will exercise substantially less well tested parts of every host
> compiler for LLVM and subject us to an increased rate of mysterious host
> compiler bugs.
>
> I also think it forces programmers to be aware of a "magical"
construct
> that doesn't really fit with the rest of the language.
>
> It isn't that any of these issues in isolation cannot be overcome, it
is
> that I think the value provided by the UDL specifically is substantially
> smaller than the cost.
>
> I would *very strongly* prefer that this is accomplished with
"normal" C++
> syntax, and that compile time checking is done with constexpr when
> available. I think that will give the overwhelming majority of the benefit
> with dramatically lower cost.
>
>
> +1, the UDL seems a bit too automagical.
> `format_string("{0}", 1)` is not that much longer than
> `"{0}"_fmt.string(1)`, but significantly less magical.
>
> Simple example: what should I type into a search engine to find the LLVM
> doxygen for the UDL? I know to search "llvm format_string" for
the format
> string, but just from looking at a use of the UDL syntax it might not be
> clear that format_string is even called.
>
> -- Sean Silva
>
>
>
> _______________________________________________
> 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/20161101/dd8f70f9/attachment.html>