PortalPete wrote: > I don't understand why step 2 is necessary; what does the optional actually > add? Is there a useful distinction between "I got an optional that was empty" > and "I got a ValueObjectSP with an error"? I didn't see any places where you > use that distinction. > > Returning the optional is also awkward because we either have to check that > the optional had a value and THEN check that GetError().Success() returns > true, which is awkward, or we have to add the rule that if an optional return > is not empty, then the ValueObjectSP is not in the error state, which is also > a bit odd.
Step 2 is necessary now that the new sub-class design doesn't allow for `null` shared pointers. Returning an optional is now the (remaining) best option to for a function/method to say "I have nothing to return to you, but it's not an error" in its return value. The vast majority of places that return an error inside the Value Object return `ValueObjectSP`, not an optional of one. I agree it's awkward, but you can think of it as a different way to represent the same awkwardness that's already been there with the existing tri-state approach: - `valueObjectSP == nullptr` - `valueObjectSP != nullptr` && `valueObjectSP->Fail()` - `valueObjectSP != nullptr` && `valueObjectSP->Success()` https://github.com/llvm/llvm-project/pull/77375 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
