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)<br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 31, 2016 at 5:45 PM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">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 <br class="gmail_msg"><br class="gmail_msg">In any case, both syntaxes are currently supported. Is that acceptable?<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, Oct 31, 2016 at 5:21 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" class="gmail_msg" target="_blank">chandlerc@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, Oct 31, 2016 at 3:46 PM Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">Hi all,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Tentatively final version is up here: <a href="https://reviews.llvm.org/D25587" class="gmail_msg" target="_blank">https://reviews.llvm.org/D25587</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Here's a summary of (most) everything contained in this patch:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">1) UDL Syntax for outputting to a stream or converting to a string.</div><div class="gmail_msg"><font face="monospace" class="gmail_msg"> outs() << "{0}"_fmt.stream(1)</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg"> std::string S = "{0}"_fmt.string(1);</font></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I continue to have a strong objection to using UDLs for this (or anything else in LLVM).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I also think it forces programmers to be aware of a "magical" construct that doesn't really fit with the rest of the language.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div></div></div>
</blockquote></div></blockquote></div>