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

[Zachary Turner via llvm-dev]

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>