<div dir="ltr">That seems plausible (op<< for Error) - but does that handle the case mentioned above "we may not actually want to produce the string (eg: if the Logger implementation decides to filter out the formatv_object_base based on level)" - is op<< still called even with this filtering? (seems like if it was, then it wouldn't avoid the stringification costs? but if it doesn't call the op<< then it'll still fail the consume semantic requirement of llvm::Error)<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 10, 2018 at 7:03 AM Sam McCall 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">sammccall added a comment.<br>
<br>
An alternate approach in <a href="https://reviews.llvm.org/D49129" rel="noreferrer" target="_blank">https://reviews.llvm.org/D49129</a>: give `Error` an overloaded `operator<<` that has the same consume semantics at `toString` when passed rvalues.<br>
<br>
This makes `formatv`, `to_string`, `toString` all do basically the same thing (which is the only sensible thing to do when passed an rvalue).<br>
<br>
It does require minor changes to `formatv` and `to_string` to make them propagate the right kind of reference, but these seem reasonable.<br>
<br>
Overall I think I like that approach better than this one (more consistent, Error handling lives in Error.h). WDYT?<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D49013" rel="noreferrer" target="_blank">https://reviews.llvm.org/D49013</a><br>
<br>
<br>
<br>
</blockquote></div></div>