I would say format provider should be the default way to add formatting for a commonly formatted type.  Member function syntax is used to implement adaptors that allow you to override formatting behavior of a type that already has a provider.<br><br>One nice thing about F and D would be this:<br><br>formatv("Dir: {0:D}, File: {0:F}", F):<br><br>Here you only pass the argument once, but format it differently each time.  You do have a point about not getting a compiler error.  In the future i had planned to add compile time format string checking but it's a ways out.  For now we assert and then fallback to the default case of an empty style.<br><br>Also, i still haven't finished the Args stuff, so no risk of me going on a reformatting spree :)<br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 10, 2016 at 1:03 AM Pavel Labath via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">labath added a comment.<br class="gmail_msg">
<br class="gmail_msg">
This looks like a step in the right direction. I trust you won't go on a reformatting spree of the log messages until we settle on the syntax there. ;)<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
================<br class="gmail_msg">
Comment at: include/lldb/Core/ModuleSpec.h:244<br class="gmail_msg">
+      strm.Format("object_mod_time = {0:x+}",<br class="gmail_msg">
                   uint64_t(llvm::sys::toTimeT(m_object_mod_time)));<br class="gmail_msg">
     }<br class="gmail_msg">
----------------<br class="gmail_msg">
you can delete the `uint64_t` cast now. It was only there to make this portably printable.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
================<br class="gmail_msg">
Comment at: include/lldb/Host/FileSpec.h:784<br class="gmail_msg">
+///<br class="gmail_msg">
+template <> struct format_provider<lldb_private::FileSpec> {<br class="gmail_msg">
+  static void format(const lldb_private::FileSpec &F, llvm::raw_ostream &Stream,<br class="gmail_msg">
----------------<br class="gmail_msg">
I am wondering.. what is the preferred style for adding formatting capability. I sort of assumed that the `format_provider` thingy was reserved for cases where you had no control over the object being formatted (e.g. because it comes from a third party library), and that for cases like this we would use the member format function (or, to put it differently: if we're going to be using the `format_provider` everywhere, what's the point of having the member functions in the first place?).<br class="gmail_msg">
<br class="gmail_msg">
Also, my preference would be to not have the F and D styles for FileSpec. I think they are redundant, as we have FileSpec::GetFilename and FileSpec::GetDirectory, and also they are not compiler-enforced --<br class="gmail_msg">
`Formatv('{0}', fs.GetFilename())` is slightly longer than `Formatv('{0:F}', fs)`, but if I make a typo in the former one, it will be a compiler error, while the other one won't. I suppose it could be useful, if one wants to format say an array of FileSpecs using the array format syntax, but I'm not sure how often will someone want to do that *and* display only the filenames.<br class="gmail_msg">
<br class="gmail_msg">
I don't care strongly about any of these things, but I want to know what to expect.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://reviews.llvm.org/D27632" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D27632</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>