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

[Chandler Carruth via llvm-dev]

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>