As mentioned, Result<T> is an improvement for function which returns a single value, e.g. Make/Factory-like. My vote goes Result<T> for such case. For multiple return types, we have std::tuple like Antoine proposed.
François On Fri, Oct 18, 2019 at 9:19 PM Antoine Pitrou <anto...@python.org> wrote: > > > Le 18/10/2019 à 20:58, Wes McKinney a écrit : > > I'm definitely uncomfortable with the idea of deprecating Status. > > > > We have a few kinds of functions that can fail: > > > > 1. Functions with no "out" arguments > > 2. Functions with one out argument > > 3. Functions with multiple out arguments > > > > IMHO functions in category 2 are the best candidates for utilizing > > Status. In some cases, Case 3 may be more usable Result-based, but it > > can also create more work (or confusion) on the part of the developer, > > either > > > > * The T in Result<T> has to be a struct-like value that transports > > multiple pieces of data > > The T can be a std::tuple though, so you need not necessarily define a > dedicated struct type for a single API's return value. > > > Can't say I'm thrilled about having Result<void> or similar for Case > > 1-type functions (if I'm understanding what would be the solution > > there). > > Agreed. > > Regards > > Antoine.
