<div dir="ltr">Hi Rafael,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Yes, sorry, it should be Expected<Optional<Child>>, which is verbose.</blockquote><div><br></div><div>Expected<Optional<Child>> works for me. I'll update the patch.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On the iterator not being default constructable: is that an actual<br>problem in here? The private constructor would make it easy to see<br>where the Error* can be null.</blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">I think your change from Error* to Error& in the non-default constructor makes this reasonably neat: default constructed iterators are "end" markers, can't be incremented, and so don't need to have their Error* set. On the other hand, child_iterator values constructed with a valid Child will also have to have a valid Error reference passed in, and these are the only iterators that can be incremented.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Lang. </div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 8, 2016 at 12:56 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 8 July 2016 at 15:46, Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br>
> lhames added a comment.<br>
><br>
>> That would leave clients unable to detect the difference between a broken archive and an undefined symbol. I don't think we want to do that.<br>
><br>
><br>
> More accurately - dropping the Error argument would leave us unable to tell the difference, but if I understand correctly dropping the error was the main motivation for switching to Optional.<br>
<br>
<br>
</span>Yes, sorry, it should be Expected<Optional<Child>>, which is verbose.<br>
The reason I still like it best is that with the current interface it<br>
is a bit confusing where exactly one should look for the error since<br>
the use looks like<br>
<br>
StructWithErrorInIt foo = func(Error &...)<br>
<br>
It is not immediately obvious that one only needs to check error<br>
passed to func. Also, while not nearly as bad as with error_code,<br>
passing down an Error& is not as nice as returning an Expected except<br>
when there is some other big gain (like being able to use a range<br>
loop).<br>
<br>
On the iterator not being default constructable: is that an actual<br>
problem in here? The private constructor would make it easy to see<br>
where the Error* can be null.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div></div>