<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 12, 2016, at 8:07 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Oct 12, 2016 at 12:40 PM Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" class="">mehdi.amini@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 12, 2016, at 12:35 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="gmail_msg" target="_blank">zturner@google.com</a>> wrote:</div><br class="gmail_msg m_3398721641444251452Apple-interchange-newline"><div class="gmail_msg">You get compile time checking automatically when we can use c++14 though. If you use it with a string literal, you'll get compile time checking, otherwise you won’t.<br class="gmail_msg"></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><div class="gmail_msg">I understand that, but that doesn’t really address my concerns.</div></div></div><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">Here's a different example though. Suppose you're writing a tool which prints formatted output, and the field width is specified by the user.</div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">Now you NEED to build the format string at runtime, there's no other way</div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div class="gmail_msg" style="word-wrap: break-word;"><div class="gmail_msg">Maybe the problem is using a string to format this in the first place.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">For example, you could wrap the object you want to print with an adaptor in charge of padding to the right till you reach the column width.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">format(“{0}”, rPad(col_width, my_object));</div></div></blockquote><div class=""><br class=""></div>FWIW I do think that literal format strings will handle 90% or more of uses. I just don't see the benefit of needlessly banning the other cases. Because all that's going to happen is someone is going to resort to using snprintf etc, which is exactly the problem I'm trying to solve.</div></div></div></blockquote><div><br class=""></div><div>Sorry but you’re totally missing the point. If there is a need for dynamism, this should be supported, that’s not the question. My point is that generating a string that will be parsed by a format function can’t be the only solution.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote"> It's literally no extra effort to support runtime format strings, and it makes the library more flexible as a result.</div></div></div></blockquote><div><br class=""></div><div>No: it does *not* make it more flexible than a non-string based solution that have the same functionality.</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><br class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote">I'm willing to start with UDLs only because I think it will get us quite far, but as soon as I need to pass a format string through an intermediate function or something like that, I will probably check in the 3 extra lines of code to add a const char* overload format function.</div><div class="gmail_quote"><br class=""></div><div class="gmail_quote">FWIW, there's no easy way to add compile time checking of format strings until C++14, regardless of whether use UDLs or not. So that doesn't change either way.</div></div></div></blockquote></div><br class=""></body></html>