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
