OK, it sounds like people want Result<T> (at least in some circumstances). Any thoughts on migrating old APIs and what to do for new APIs going forward?
A very rough approximation [1] yields the following counts by module: 853 arrow 17 gandiva 25 parquet 50 plasma [1] grep -r Status cpp/src/* |grep ".h:" | grep "\\*" |grep -v Accept |sed s/:.*// | cut -f3 -d/ |sort Thanks, Micah On Sat, Oct 19, 2019 at 7:50 PM Francois Saint-Jacques < fsaintjacq...@gmail.com> wrote: > 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. >
