Cool. This is just the rename portion, right? Sorry I didn't respond to your last message too.
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. 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? Cheers, Lang. On Tue, May 9, 2017 at 8:58 PM, Zachary Turner <ztur...@google.com> wrote: > 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. > > On Mon, May 1, 2017 at 5:49 PM Zachary Turner <ztur...@google.com> wrote: > >> 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. >> >> On Mon, May 1, 2017 at 5:43 PM Lang Hames <lha...@gmail.com> wrote: >> >>> Hi Zachary, >>> >>> ... Then instead of Expected<T> you could have WithDiagnostics<T> that >>>> enforces the proper semantics. >>> >>> >>> 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. >>> >>> Cheers, >>> Lang. >>> >>> >>> On Mon, May 1, 2017 at 5:36 PM, Zachary Turner <ztur...@google.com> >>> wrote: >>> >>>> 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. >>>> >>>> On Mon, May 1, 2017 at 5:33 PM Zachary Turner <ztur...@google.com> >>>> wrote: >>>> >>>>> On Mon, May 1, 2017 at 5:27 PM Jim Ingham <jing...@apple.com> wrote: >>>>> >>>>>> >>>>>> > On May 1, 2017, at 4:52 PM, Zachary Turner <ztur...@google.com> >>>>>> wrote: >>>>>> > >>>>>> > 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: >>>>>> > >>>>>> > int getNumberOfSymbols(Error &Err) {} >>>>>> > >>>>>> > or >>>>>> > >>>>>> > Error getNumberOfSymbols(int &Count) {} >>>>>> > >>>>>> > You would now write: >>>>>> > >>>>>> > Expected<int> getNumberOfSymbols() { >>>>>> > if (foo) return 1; >>>>>> > else return make_error<DWARFError>("No symbols!"); >>>>>> > } >>>>>> > >>>>>> > and on the caller side you write: >>>>>> > >>>>>> > Error processAllSymbols() { >>>>>> > if (auto Syms = getNumberOfSymbols()) { >>>>>> > outs() << "There are " << *Syms << " symbols!"; >>>>>> > } else { >>>>>> > return Syms.takeError(); >>>>>> > // alternatively, you could write: >>>>>> > // consumeError(Syms.takeError()); >>>>>> > // return Error::success(); >>>>>> > } >>>>>> > } >>>>>> > >>>>>> >>>>>> Interesting. >>>>>> >>>>>> 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. >>>>>> >>>>>> Jim >>>>>> >>>>> >>>>> 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. >>>>> >>>>> In that case you could return an error such as this. >>>>> >>>>> 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. >>>>> >>>> >>>
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev