Actually I should elaborate because this is a tad misleading.<br><br>If the *syntax* is illegal it will ignore.  Like if you write {0;} or {0{.  In this case the entire thing is pasted into the output and no replacement happens.<br><br>If it can successfully parse into X, Y, and Z where X is the index, Y is the alignment, and Z is the option string, then what happens depends on which of X, Y, and Z are illegal.<br><br>If X is empty the sequence is replaced with an empty string.  Otherwise, If X is not a positive integer the sequence is pasted into the output and everything else ignored.<br><br>If Y is illegal, Y is ignored as if it wasn't specified.<br><br>Whether Z is illegal is up to the format provider, so each one decides how to react to an invalid string <br><br>Note that any point here we can assert.  This would allow us to catch these in debug builds while silently doing the best we can in non debug builds<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 12, 2016 at 6:11 AM 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"><div style="white-space:pre-wrap" class="gmail_msg">In my current implementation, it's up to the format provider.  If you have an illegal format spec (eg {0;0}) it ignores it and prints the format spec as a literal.  We could also add an assert here in theory.<br class="gmail_msg"><br class="gmail_msg">If/when we move to c++14, a constexpr StringRef implementation would allow us to parse and validate the entire format string at compile time.<br class="gmail_msg"><br class="gmail_msg">Since conciseness is one of the main goals of a library such as this, I would hate to actively hamper this for more compile time checking.  If you write an invalid format spec presumably your test will fail since it will ignore it</div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Oct 12, 2016 at 2:34 AM Pavel Labath <<a href="mailto:labath@google.com" class="gmail_msg" target="_blank">labath@google.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">On 12 October 2016 at 05:26, Zachary Turner via llvm-dev<br class="gmail_msg">
<<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg">
> os << format_string("Start: {0}, End: {1}, Elapsed: {2:ms}", start, end,<br class="gmail_msg">
> start-end);<br class="gmail_msg">
<br class="gmail_msg">
What would happen if I accidentally type "ps" instead of "ms" (I am<br class="gmail_msg">
assuming we will not support picoseconds here)?<br class="gmail_msg">
<br class="gmail_msg">
Will this abort at runtime?<br class="gmail_msg">
<br class="gmail_msg">
I would prefer if *all* arguments to the format were checkable at compile time:<br class="gmail_msg">
I.e. something like:<br class="gmail_msg">
os << "blah blah" << format<std::milli>(end-start) << "blah blah";<br class="gmail_msg">
<br class="gmail_msg">
I understand this may clash a bit with the desire for a compact<br class="gmail_msg">
representation, but maybe with some clever design we could achieve<br class="gmail_msg">
both?<br class="gmail_msg">
<br class="gmail_msg">
pl<br class="gmail_msg">
</blockquote></div></blockquote></div>