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

Zachary Turner via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 31 18:01:05 PDT 2016


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>


More information about the llvm-dev mailing list