<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 12:26 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9 October 2014 15:44, Justin Bogner <<a href="mailto:mail@justinbogner.com">mail@justinbogner.com</a>> wrote:<br>
> Alexander Kornienko <<a href="mailto:alexfh@google.com">alexfh@google.com</a>> writes:<br>
>> This method allows writing code that consistently fails in case of<br>
>> dereferencing an ErrorOr<> containing no value rather than crashing in<br>
>> debug and using uninitialized data in release build.<br>
><br>
> I don't see why this would be better than doing this check in the<br>
> caller, for two reasons:<br>
><br>
> 1. Situations where report_fatal_error is the right thing are fairly<br>
>    rare, so I wouldn't expect it to be a lot of boilerplate.<br>
><br>
> 2. The caller generally can and should report a more specific error<br>
<br>
</span>I don't thing anyone disagrees that a nice error message is a feature,<br>
but it might not be the priority of every code to use a SMDiagnostic.<br>
Using report_fatal_error is a reasonable way to start (or an<br>
improvement over a misplaced assert/unreachable, like we have in parts<br>
of LLVM (pr20485 for example)).<br>
<br>
Having said that, calling report_fatal_error in a class that is pretty<br>
independent from llvm looks a bit odd.</blockquote><div><br></div><div>Well, this class is a part of LLVM, so it could use other LLVM facilities.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Could we maybe have something<br>
like<br>
<br>
template<typename T><br>
const T& extractOrDie(const ErrorOr<T> &V) {<br>
  if (V)<br>
    return *V;<br>
  report_fatal_error("foo");<br>
}<br>
<br>
defined in some other header?<br></blockquote><div><br></div><div>It can be a standalone function, if you think that it makes sense keeping ErrorOr<> dependencies on LLVM minimal. But the function would be closely tied to ErrorOr<>, and it looks reasonable to put it to the same header.</div><div><br></div><div>-- Alex</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><div><br></div>
</div></div>