<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 5, 2013 at 9:04 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">The attached patch removes another unused, and IMHO, not very<br>
desirable feature of ErrorOr.<br>
<br>
One of the uses of the IsValid flag is to support default constructing<br>
a ErrorOr that is not a Error or a Value. There is not much value in<br>
doing that IMHO. If ErrorOr was to have a default constructor, it<br>
should be implemented by default constructing the value, but even that<br>
looks unnecessary.<br>
<br>
The other use is to avoid calling destructors on moved objects. This<br>
looks wrong. If the data being moved has non trivial treatment of<br>
moves (an std::vector for example), it is its destructor that should<br>
handle it, not ~ErrorOr.<br></blockquote><div><br></div><div>I sort of like this functionality, but I agree with your logic that it's not strictly the purview of this type to handle this case (I'm still on the fence). In any case it looks like this functionality was misimplemented/broken anyway - the moved-from data object never gets its dtor run by the ErrorOr move ctor...   </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
With this change ErrorOr becomes a fairly simple wrapper and should<br>
always be better than using an error_code + value in an API.<br>
<br>
Cheers,<br>
Rafael<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>