arrow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Micah Kornfield <emkornfi...@gmail.com>
Subject Re: [DISCUSS] Result vs Status
Date Thu, 24 Oct 2019 02:22:53 GMT
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 <
fsaintjacques@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 <antoine@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message