<div dir="ltr">Yes, this is just the rename.<div><br></div><div>Regarding the naming, if you call it ErrorAnd, or WithError, or anything that includes the word error, you are implying that something actually went wrong. I don't think that's the intended use case, or at least not what I have in mind (and from previous conversations on the list, I don't think what Jim had in mind either).</div><div><br></div><div>If we're going to say that something does not need to be handled, I don't know if we should be calling it an error at all. By definition, we should assert that errors must be handled, so the converse is that if it doesn't need to be handled, it's not an error.</div><div><br></div><div>But if it does need to be handled (and as such is called an error), then I'm not sure if it makes sense to say there's also a value. So ErrorOr, or Expected seems to convey that meaning in the only way possible. If you don't get the thing you're expected to get, you need to handle the error.</div><div><br></div><div>But it seemed like what we were talking was more of a way to provide diagnostic information about a long process that you could return alongside a result. And if you don't get one, you don't necessarily care. So it's like one step down in the expectation chain from Expected. Possible<T> maybe?</div><div><br></div><div>I would expect an interface similar to Optional<T>, but with a way to get error *like* diagnostic information or messages that the user could ignore if they wanted to.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 10, 2017 at 6:09 PM Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Cool. This is just the rename portion, right?<div><br></div><div>Sorry I didn't respond to your last message too.</div></div><div dir="ltr"><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">I suppose, but I'm not sure ErrorAnd captures the intended meaning very well. In any case, that's not super important at this stage since this isn't on the immediate horizon.</blockquote><div><br></div></div><div dir="ltr"><div>Do you just mean that ErrorAnd isn't an especially nice name? I wasn't entirely sure what make_status<T>(...) was supposed to do so I assumed it was to create a pair of an Error and a T. If that's the case, make_with_error<T>(T, Error) (and WithError<T>) might be better names?</div><div><br></div><div>Cheers,</div><div>Lang.</div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 9, 2017 at 8:58 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm probably going to be looking at submitting this this week, more likely sooner rather than later. If I can get it all working hopefully even tomorrow.</div><div class="m_-5439268643505584859HOEnZb"><div class="m_-5439268643505584859h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, May 1, 2017 at 5:49 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I suppose, but I'm not sure ErrorAnd captures the intended meaning very well. In any case, that's not super important at this stage since this isn't on the immediate horizon.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, May 1, 2017 at 5:43 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Zachary,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">... Then instead of Expected<T> you could have WithDiagnostics<T> that enforces the proper semantics.</blockquote><div><br></div><div>You mean something like an ErrorAnd<T>? Chris Bieneman floated that idea for some libObject code but we haven't got around to implementing it. If it were generically useful we could do something like that.</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 1, 2017 at 5:36 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Is there any chance of introducing something like make_status<T>() into llvm/Error.h, that constructs the llvm::Error in such a way that it still interoperates nicely with everything else? Then instead of Expected<T> you could have WithDiagnostics<T> that enforces the proper semantics.</div><div class="m_-5439268643505584859m_-3636644137126258081m_-2886354936752614003m_-2013066891587853428HOEnZb"><div class="m_-5439268643505584859m_-3636644137126258081m_-2886354936752614003m_-2013066891587853428h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, May 1, 2017 at 5:33 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, May 1, 2017 at 5:27 PM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 1, 2017, at 4:52 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> Yea, grouping the error and the result together is one of the most compelling features of it. It's called Expected<T>, so where we would currently write something like:<br>
><br>
> int getNumberOfSymbols(Error &Err) {}<br>
><br>
> or<br>
><br>
> Error getNumberOfSymbols(int &Count) {}<br>
><br>
> You would now write:<br>
><br>
> Expected<int> getNumberOfSymbols() {<br>
> if (foo) return 1;<br>
> else return make_error<DWARFError>("No symbols!");<br>
> }<br>
><br>
> and on the caller side you write:<br>
><br>
> Error processAllSymbols() {<br>
> if (auto Syms = getNumberOfSymbols()) {<br>
> outs() << "There are " << *Syms << " symbols!";<br>
> } else {<br>
> return Syms.takeError();<br>
> // alternatively, you could write:<br>
> // consumeError(Syms.takeError());<br>
> // return Error::success();<br>
> }<br>
> }<br>
><br>
<br>
Interesting.<br>
<br>
This pattern doesn't quite work for fetching symbols - maybe that really is more suitable as a Status than an Error. After all, number of symbols == 0 is not necessarily an error, there just might not have been any symbols (e.g. a fully stripped main); and I'm going to work on whatever symbols I get back, since there's nothing I can do about the ones that didn't make it. I just want to propagate the error so the user knows that there was a problem.<br>
<br>
Jim<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Sure, that was just a made up example. You could imagine that being some private function deep in the implementation details of a symbol parser, where you've got some header that's supposed to be N bytes, and getNumberOfSymbols() seeks to offset 42 and reads a 4 byte value and returns it, but the function sees that there's only 40 bytes in the header, so it's not that there's no symbols, it's that something is seriously messed up.</div><div><br></div><div>In that case you could return an error such as this.</div><div><br></div><div>Of course, the person who called this function can either propagate it, deal with it some other way and mask it, or whatever. Mostly I was just trying to show what the syntax looked like for grouping return values with errors. </div></div></div></blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div></blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div>