You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Ben Kietzman <be...@rstudio.com> on 2019/10/02 16:43:22 UTC
[DISCUSS] Result vs Status
The C++ library has two classes which fill mostly the same function. Both
Status and Result<> are used to express a recoverable error in lieu of
exceptions. Result<> is slightly more ergonomic in C++, but our binding
infrastructures assume Status based APIs.
From the discussion in the sync call, it seems reasonable to require that:
Public APIs which are likely to be directly wrapped in a binding should not
use Result<> to the exclusion of Status. An equivalent Status API should
always be provided for ease of binding.
Re: [DISCUSS] Result vs Status
Posted by Micah Kornfield <em...@gmail.com>.
Hi Omer,
I think this is really cool. It is quite possible it was underestimated (I
agree about line lengths), but I think the clang query is double counting
somehow.
For instance:
"grep -r Status *" only returns ~9000 results in total for me.
Similarly using grep for "FinishTyped" returns 18 results for me.
Searching through the log that you linked seems to return 450 (for "Status
FinishTyped").
It is quite possible, I'm doing something naive with grep.
Thanks,
Micah
On Thu, Oct 24, 2019 at 2:41 PM Omer F. Ozarslan <om...@utdallas.edu> wrote:
> Forgot to mention most of those lines are longer than line width while
> out is usually (always?) last parameter, so probably that's why grep
> possibly underestimates their number.
>
> On Thu, Oct 24, 2019 at 4:33 PM Omer F. Ozarslan <om...@utdallas.edu>
> wrote:
> >
> > Hi,
> >
> > I don't have much experience on customized clang-tidy plugins, but
> > this might be a good use case for such a plugin from what I read here
> > and there (frankly this was a good excuse for me to have a look at
> > clang tooling as well). I wanted to ensure it isn't obviously overkill
> > before this suggestion: Running a clang query which lists functions
> > returning `arrow::Status` and taking a pointer parameter named `out`
> > showed that there are 13947 such functions in `cpp/src/**/*.h`. [1]
> >
> > I checked logs and it seemed legitimate to me, but please check it in
> > case I missed something. If that's the case, it might be tedious to do
> > this work manually.
> >
> > [1]: https://gist.github.com/ozars/ecbb1b8acd4a57ba4721c1965f83f342
> > (Note that the log file is shown as truncated by github after ~30k
> > lines)
> >
> > Best,
> > Omer
> >
> >
> >
> > On Wed, Oct 23, 2019 at 9:23 PM Micah Kornfield <em...@gmail.com>
> wrote:
> > >
> > > 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 <an...@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.
> > > >
>
Re: [DISCUSS] Result vs Status
Posted by Micah Kornfield <em...@gmail.com>.
This seems reasonable to me. Give the impact of the API changes I think it
might be worth keeping around for ~3 releases, but I think we are generally
slow to delete deprecated APIs anyways.
Any other thoughts on this? i can try to open up some tracking JIRAs for
the work involved.
On Wed, Oct 30, 2019 at 1:25 PM Wes McKinney <we...@gmail.com> wrote:
> Returning to this discussion.
>
> Here is my position on the matter since this was brought up on the
> sync call today
>
> * For internal / non-public and pseudo-non-public APIs that have
> return/out values
> - Use Result or Status at discretion of the developer, but Result<T>
> is preferable
>
> * For new public APIs with return/out values
> - Prefer Result<T> unless a Status-based API seems definitely less
> awkward in real world use. I have to say that I'm skeptical about the
> relative usability of std::tuple outputs and don't think we should
> force the use of Result<T> for technical purity reasons
>
> * For existing Status APIs with return values
> - Incrementally add Result<T> APIs and deprecate Status-based APIs.
> Maintain deprecated Status APIs for ~2 major releases
>
> On Thu, Oct 24, 2019 at 5:16 PM Omer F. Ozarslan <om...@utdallas.edu>
> wrote:
> >
> > Hi Micah,
> >
> > You're right. Quite possible that clang-query counted same function
> > separately for each include in each file. (I was iterating each file
> > separately, but providing all of them at once didn't change the result
> > either.)
> >
> > It's cool and wrong, so not very useful apparently. :-)
> >
> > Best,
> > Omer
> >
> > On Thu, Oct 24, 2019 at 4:51 PM Micah Kornfield <em...@gmail.com>
> wrote:
> > >
> > > Hi Omer,
> > > I think this is really cool. It is quite possible it was
> underestimated (I agree about line lengths), but I think the clang query is
> double counting somehow.
> > >
> > > For instance:
> > >
> > > "grep -r Status *" only returns ~9000 results in total for me.
> > >
> > > Similarly using grep for "FinishTyped" returns 18 results for me.
> Searching through the log that you linked seems to return 450 (for "Status
> FinishTyped").
> > >
> > > It is quite possible, I'm doing something naive with grep.
> > >
> > > Thanks,
> > > Micah
> > >
> > > On Thu, Oct 24, 2019 at 2:41 PM Omer F. Ozarslan <om...@utdallas.edu>
> wrote:
> > >>
> > >> Forgot to mention most of those lines are longer than line width while
> > >> out is usually (always?) last parameter, so probably that's why grep
> > >> possibly underestimates their number.
> > >>
> > >> On Thu, Oct 24, 2019 at 4:33 PM Omer F. Ozarslan <om...@utdallas.edu>
> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > I don't have much experience on customized clang-tidy plugins, but
> > >> > this might be a good use case for such a plugin from what I read
> here
> > >> > and there (frankly this was a good excuse for me to have a look at
> > >> > clang tooling as well). I wanted to ensure it isn't obviously
> overkill
> > >> > before this suggestion: Running a clang query which lists functions
> > >> > returning `arrow::Status` and taking a pointer parameter named `out`
> > >> > showed that there are 13947 such functions in `cpp/src/**/*.h`. [1]
> > >> >
> > >> > I checked logs and it seemed legitimate to me, but please check it
> in
> > >> > case I missed something. If that's the case, it might be tedious to
> do
> > >> > this work manually.
> > >> >
> > >> > [1]: https://gist.github.com/ozars/ecbb1b8acd4a57ba4721c1965f83f342
> > >> > (Note that the log file is shown as truncated by github after ~30k
> > >> > lines)
> > >> >
> > >> > Best,
> > >> > Omer
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Oct 23, 2019 at 9:23 PM Micah Kornfield <
> emkornfield@gmail.com> wrote:
> > >> > >
> > >> > > 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.
> > >> > > >
>
Re: [DISCUSS] Result vs Status
Posted by Wes McKinney <we...@gmail.com>.
Returning to this discussion.
Here is my position on the matter since this was brought up on the
sync call today
* For internal / non-public and pseudo-non-public APIs that have
return/out values
- Use Result or Status at discretion of the developer, but Result<T>
is preferable
* For new public APIs with return/out values
- Prefer Result<T> unless a Status-based API seems definitely less
awkward in real world use. I have to say that I'm skeptical about the
relative usability of std::tuple outputs and don't think we should
force the use of Result<T> for technical purity reasons
* For existing Status APIs with return values
- Incrementally add Result<T> APIs and deprecate Status-based APIs.
Maintain deprecated Status APIs for ~2 major releases
On Thu, Oct 24, 2019 at 5:16 PM Omer F. Ozarslan <om...@utdallas.edu> wrote:
>
> Hi Micah,
>
> You're right. Quite possible that clang-query counted same function
> separately for each include in each file. (I was iterating each file
> separately, but providing all of them at once didn't change the result
> either.)
>
> It's cool and wrong, so not very useful apparently. :-)
>
> Best,
> Omer
>
> On Thu, Oct 24, 2019 at 4:51 PM Micah Kornfield <em...@gmail.com> wrote:
> >
> > Hi Omer,
> > I think this is really cool. It is quite possible it was underestimated (I agree about line lengths), but I think the clang query is double counting somehow.
> >
> > For instance:
> >
> > "grep -r Status *" only returns ~9000 results in total for me.
> >
> > Similarly using grep for "FinishTyped" returns 18 results for me. Searching through the log that you linked seems to return 450 (for "Status FinishTyped").
> >
> > It is quite possible, I'm doing something naive with grep.
> >
> > Thanks,
> > Micah
> >
> > On Thu, Oct 24, 2019 at 2:41 PM Omer F. Ozarslan <om...@utdallas.edu> wrote:
> >>
> >> Forgot to mention most of those lines are longer than line width while
> >> out is usually (always?) last parameter, so probably that's why grep
> >> possibly underestimates their number.
> >>
> >> On Thu, Oct 24, 2019 at 4:33 PM Omer F. Ozarslan <om...@utdallas.edu> wrote:
> >> >
> >> > Hi,
> >> >
> >> > I don't have much experience on customized clang-tidy plugins, but
> >> > this might be a good use case for such a plugin from what I read here
> >> > and there (frankly this was a good excuse for me to have a look at
> >> > clang tooling as well). I wanted to ensure it isn't obviously overkill
> >> > before this suggestion: Running a clang query which lists functions
> >> > returning `arrow::Status` and taking a pointer parameter named `out`
> >> > showed that there are 13947 such functions in `cpp/src/**/*.h`. [1]
> >> >
> >> > I checked logs and it seemed legitimate to me, but please check it in
> >> > case I missed something. If that's the case, it might be tedious to do
> >> > this work manually.
> >> >
> >> > [1]: https://gist.github.com/ozars/ecbb1b8acd4a57ba4721c1965f83f342
> >> > (Note that the log file is shown as truncated by github after ~30k
> >> > lines)
> >> >
> >> > Best,
> >> > Omer
> >> >
> >> >
> >> >
> >> > On Wed, Oct 23, 2019 at 9:23 PM Micah Kornfield <em...@gmail.com> wrote:
> >> > >
> >> > > 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 <an...@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.
> >> > > >
Re: [DISCUSS] Result vs Status
Posted by "Omer F. Ozarslan" <om...@utdallas.edu>.
Hi Micah,
You're right. Quite possible that clang-query counted same function
separately for each include in each file. (I was iterating each file
separately, but providing all of them at once didn't change the result
either.)
It's cool and wrong, so not very useful apparently. :-)
Best,
Omer
On Thu, Oct 24, 2019 at 4:51 PM Micah Kornfield <em...@gmail.com> wrote:
>
> Hi Omer,
> I think this is really cool. It is quite possible it was underestimated (I agree about line lengths), but I think the clang query is double counting somehow.
>
> For instance:
>
> "grep -r Status *" only returns ~9000 results in total for me.
>
> Similarly using grep for "FinishTyped" returns 18 results for me. Searching through the log that you linked seems to return 450 (for "Status FinishTyped").
>
> It is quite possible, I'm doing something naive with grep.
>
> Thanks,
> Micah
>
> On Thu, Oct 24, 2019 at 2:41 PM Omer F. Ozarslan <om...@utdallas.edu> wrote:
>>
>> Forgot to mention most of those lines are longer than line width while
>> out is usually (always?) last parameter, so probably that's why grep
>> possibly underestimates their number.
>>
>> On Thu, Oct 24, 2019 at 4:33 PM Omer F. Ozarslan <om...@utdallas.edu> wrote:
>> >
>> > Hi,
>> >
>> > I don't have much experience on customized clang-tidy plugins, but
>> > this might be a good use case for such a plugin from what I read here
>> > and there (frankly this was a good excuse for me to have a look at
>> > clang tooling as well). I wanted to ensure it isn't obviously overkill
>> > before this suggestion: Running a clang query which lists functions
>> > returning `arrow::Status` and taking a pointer parameter named `out`
>> > showed that there are 13947 such functions in `cpp/src/**/*.h`. [1]
>> >
>> > I checked logs and it seemed legitimate to me, but please check it in
>> > case I missed something. If that's the case, it might be tedious to do
>> > this work manually.
>> >
>> > [1]: https://gist.github.com/ozars/ecbb1b8acd4a57ba4721c1965f83f342
>> > (Note that the log file is shown as truncated by github after ~30k
>> > lines)
>> >
>> > Best,
>> > Omer
>> >
>> >
>> >
>> > On Wed, Oct 23, 2019 at 9:23 PM Micah Kornfield <em...@gmail.com> wrote:
>> > >
>> > > 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 <an...@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.
>> > > >
Re: [DISCUSS] Result vs Status
Posted by "Omer F. Ozarslan" <om...@utdallas.edu>.
Forgot to mention most of those lines are longer than line width while
out is usually (always?) last parameter, so probably that's why grep
possibly underestimates their number.
On Thu, Oct 24, 2019 at 4:33 PM Omer F. Ozarslan <om...@utdallas.edu> wrote:
>
> Hi,
>
> I don't have much experience on customized clang-tidy plugins, but
> this might be a good use case for such a plugin from what I read here
> and there (frankly this was a good excuse for me to have a look at
> clang tooling as well). I wanted to ensure it isn't obviously overkill
> before this suggestion: Running a clang query which lists functions
> returning `arrow::Status` and taking a pointer parameter named `out`
> showed that there are 13947 such functions in `cpp/src/**/*.h`. [1]
>
> I checked logs and it seemed legitimate to me, but please check it in
> case I missed something. If that's the case, it might be tedious to do
> this work manually.
>
> [1]: https://gist.github.com/ozars/ecbb1b8acd4a57ba4721c1965f83f342
> (Note that the log file is shown as truncated by github after ~30k
> lines)
>
> Best,
> Omer
>
>
>
> On Wed, Oct 23, 2019 at 9:23 PM Micah Kornfield <em...@gmail.com> wrote:
> >
> > 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 <an...@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.
> > >
Re: [DISCUSS] Result vs Status
Posted by "Omer F. Ozarslan" <om...@utdallas.edu>.
Hi,
I don't have much experience on customized clang-tidy plugins, but
this might be a good use case for such a plugin from what I read here
and there (frankly this was a good excuse for me to have a look at
clang tooling as well). I wanted to ensure it isn't obviously overkill
before this suggestion: Running a clang query which lists functions
returning `arrow::Status` and taking a pointer parameter named `out`
showed that there are 13947 such functions in `cpp/src/**/*.h`. [1]
I checked logs and it seemed legitimate to me, but please check it in
case I missed something. If that's the case, it might be tedious to do
this work manually.
[1]: https://gist.github.com/ozars/ecbb1b8acd4a57ba4721c1965f83f342
(Note that the log file is shown as truncated by github after ~30k
lines)
Best,
Omer
On Wed, Oct 23, 2019 at 9:23 PM Micah Kornfield <em...@gmail.com> wrote:
>
> 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 <an...@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.
> >
Re: [DISCUSS] Result vs Status
Posted by Micah Kornfield <em...@gmail.com>.
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 <an...@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.
>
Re: [DISCUSS] Result vs Status
Posted by Francois Saint-Jacques <fs...@gmail.com>.
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 <an...@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.
Re: [DISCUSS] Result vs Status
Posted by Antoine Pitrou <an...@python.org>.
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.
Re: [DISCUSS] Result vs Status
Posted by Micah Kornfield <em...@gmail.com>.
Hi Wes,
Sorry for the confusion I agree completely with what you wrote. I was only
thinking about scenario 2 and 3 (where it makes sense) in my previous email.
TL;DR; in the long term I don't think we should be supporting semantically
equivilent APIs for both Status and Result.
I'll see if I can get an estimate of APIs that would change
Thanks,
Micah
On Friday, October 18, 2019, Wes McKinney <we...@gmail.com> wrote:
> On Fri, Oct 18, 2019 at 7:58 PM Wes McKinney <we...@gmail.com> wrote:
> >
> > 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
>
> typo
>
> "category 2 are the best candidates for utilizing Result"
>
> > * The T in Result<T> has to be a struct-like value that transports
> > multiple pieces of data
> > * "Out" data may be split across a Result<T> and a separate out
> > argument. That's not too nice
> >
> > 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).
> >
> > Left to my own devices I would either use only Status or use Result
> > when it is convenient for functions that have a single out argument
> >
> > I don't know how many functions or methods we have in the codebase
> > returning Status but I'd guess it's getting on the order of 1000. A
> > proper accounting would be helpful
> >
> > - Wes
> >
> > On Fri, Oct 18, 2019 at 2:41 AM Micah Kornfield <em...@gmail.com>
> wrote:
> > >
> > > Based on the call this week, I think there are a few related questions
> here.
> > >
> > > 1. Should we use Result at all?
> > > - IMO Result expresses APIs more naturally then Status + Single output
> > > parameter. I think most would agree if we had it from the beginning we
> > > would be probably use it.
> > > - The downside to using it is the pain in incorporating it into the
> > > codebase, including the potential for inconsistent APIs and breaking
> > > consumers of the package. It also has the potential to cause ABI
> problems
> > > with other projects due its use of a vendored "Variant"
> implementations.
> > >
> > > 2. If we agree on using Result in the code-base going forward (i.e. we
> > > don't remove it altogether), how do we move forward when working with
> APIs?
> > >
> > > This can be divided into existing and new APIs.
> > >
> > > For existing APIs we can:
> > > 1. Leave existing APIs in place with no plans to migrate them to using
> > > Result.
> > > 2. Aim to maintain both Result and Status APIs (backfill Result APIs
> where
> > > it makes sense).
> > > 3. Aim to migrate to Result APIs (backfill Result APIs and deprecate
> > > Status APIs). I assume this process will take at least 1 calendar year
> > > (its one of the things I'm hoping to get to). This is probably best
> done
> > > incrementally by submodule. I think for a change on this scale we
> should
> > > mark old APIs as deprecated and leave them in place for at least 2
> release
> > > cycles (at the current cadence 6 months).
> > >
> > > For new APIs:
> > > 1. Attempt to always have both versions (Result and Status) of the API
> > > everywhere that it makes sense.
> > > 2. Produce both versions of the API until we are ready to deprecate
> Status
> > > APIs in one go.
> > > 3. Only produce APIs using Result.
> > >
> > > My personal preference would be to choose to use Result and proceed
> with
> > > Option 3 for existing APIs (aim for deprecation of Status) and Option
> 3 for
> > > new APIs (only use Result going forward). My second preference would
> be to
> > > simply remove "Result". I don't want to be supporting parallel APIs
> in the
> > > long term.
> > >
> > > Thanks,
> > > Micah
> > >
> > >
> > >
> > > On Sat, Oct 5, 2019 at 4:59 AM Sutou Kouhei <ko...@clear-code.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > In <21...@python.org>
> > > > "Re: [DISCUSS] Result vs Status" on Sat, 5 Oct 2019 12:23:05 +0200,
> > > > Antoine Pitrou <an...@python.org> wrote:
> > > >
> > > > >> OK, so what could more context be provided on:
> > > > >>
> > > > >>> From the discussion in the sync call, it seems reasonable to
> require
> > > > that:
> > > > >>> Public APIs which are likely to be directly wrapped in a binding
> > > > should not
> > > > >>> use Result<> to the exclusion of Status. An equivalent Status API
> > > > should
> > > > >>> always be provided for ease of binding.
> > > > >
> > > > > I don't know, sorry :-) I wasn't on the sync call.
> > > >
> > > >
> > > > We don't need Status API for bindings. We already use
> > > > complex types such as std::shared_ptr in our API. Bindings
> > > > need C++ feature for complex types. So we don't need to care
> > > > about Result<> or Status.
> > > >
> > > >
> > > > Thanks,
> > > > --
> > > > kou
> > > >
>
Re: [DISCUSS] Result vs Status
Posted by Wes McKinney <we...@gmail.com>.
On Fri, Oct 18, 2019 at 7:58 PM Wes McKinney <we...@gmail.com> wrote:
>
> 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
typo
"category 2 are the best candidates for utilizing Result"
> * The T in Result<T> has to be a struct-like value that transports
> multiple pieces of data
> * "Out" data may be split across a Result<T> and a separate out
> argument. That's not too nice
>
> 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).
>
> Left to my own devices I would either use only Status or use Result
> when it is convenient for functions that have a single out argument
>
> I don't know how many functions or methods we have in the codebase
> returning Status but I'd guess it's getting on the order of 1000. A
> proper accounting would be helpful
>
> - Wes
>
> On Fri, Oct 18, 2019 at 2:41 AM Micah Kornfield <em...@gmail.com> wrote:
> >
> > Based on the call this week, I think there are a few related questions here.
> >
> > 1. Should we use Result at all?
> > - IMO Result expresses APIs more naturally then Status + Single output
> > parameter. I think most would agree if we had it from the beginning we
> > would be probably use it.
> > - The downside to using it is the pain in incorporating it into the
> > codebase, including the potential for inconsistent APIs and breaking
> > consumers of the package. It also has the potential to cause ABI problems
> > with other projects due its use of a vendored "Variant" implementations.
> >
> > 2. If we agree on using Result in the code-base going forward (i.e. we
> > don't remove it altogether), how do we move forward when working with APIs?
> >
> > This can be divided into existing and new APIs.
> >
> > For existing APIs we can:
> > 1. Leave existing APIs in place with no plans to migrate them to using
> > Result.
> > 2. Aim to maintain both Result and Status APIs (backfill Result APIs where
> > it makes sense).
> > 3. Aim to migrate to Result APIs (backfill Result APIs and deprecate
> > Status APIs). I assume this process will take at least 1 calendar year
> > (its one of the things I'm hoping to get to). This is probably best done
> > incrementally by submodule. I think for a change on this scale we should
> > mark old APIs as deprecated and leave them in place for at least 2 release
> > cycles (at the current cadence 6 months).
> >
> > For new APIs:
> > 1. Attempt to always have both versions (Result and Status) of the API
> > everywhere that it makes sense.
> > 2. Produce both versions of the API until we are ready to deprecate Status
> > APIs in one go.
> > 3. Only produce APIs using Result.
> >
> > My personal preference would be to choose to use Result and proceed with
> > Option 3 for existing APIs (aim for deprecation of Status) and Option 3 for
> > new APIs (only use Result going forward). My second preference would be to
> > simply remove "Result". I don't want to be supporting parallel APIs in the
> > long term.
> >
> > Thanks,
> > Micah
> >
> >
> >
> > On Sat, Oct 5, 2019 at 4:59 AM Sutou Kouhei <ko...@clear-code.com> wrote:
> >
> > > Hi,
> > >
> > > In <21...@python.org>
> > > "Re: [DISCUSS] Result vs Status" on Sat, 5 Oct 2019 12:23:05 +0200,
> > > Antoine Pitrou <an...@python.org> wrote:
> > >
> > > >> OK, so what could more context be provided on:
> > > >>
> > > >>> From the discussion in the sync call, it seems reasonable to require
> > > that:
> > > >>> Public APIs which are likely to be directly wrapped in a binding
> > > should not
> > > >>> use Result<> to the exclusion of Status. An equivalent Status API
> > > should
> > > >>> always be provided for ease of binding.
> > > >
> > > > I don't know, sorry :-) I wasn't on the sync call.
> > >
> > >
> > > We don't need Status API for bindings. We already use
> > > complex types such as std::shared_ptr in our API. Bindings
> > > need C++ feature for complex types. So we don't need to care
> > > about Result<> or Status.
> > >
> > >
> > > Thanks,
> > > --
> > > kou
> > >
Re: [DISCUSS] Result vs Status
Posted by Wes McKinney <we...@gmail.com>.
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
* "Out" data may be split across a Result<T> and a separate out
argument. That's not too nice
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).
Left to my own devices I would either use only Status or use Result
when it is convenient for functions that have a single out argument
I don't know how many functions or methods we have in the codebase
returning Status but I'd guess it's getting on the order of 1000. A
proper accounting would be helpful
- Wes
On Fri, Oct 18, 2019 at 2:41 AM Micah Kornfield <em...@gmail.com> wrote:
>
> Based on the call this week, I think there are a few related questions here.
>
> 1. Should we use Result at all?
> - IMO Result expresses APIs more naturally then Status + Single output
> parameter. I think most would agree if we had it from the beginning we
> would be probably use it.
> - The downside to using it is the pain in incorporating it into the
> codebase, including the potential for inconsistent APIs and breaking
> consumers of the package. It also has the potential to cause ABI problems
> with other projects due its use of a vendored "Variant" implementations.
>
> 2. If we agree on using Result in the code-base going forward (i.e. we
> don't remove it altogether), how do we move forward when working with APIs?
>
> This can be divided into existing and new APIs.
>
> For existing APIs we can:
> 1. Leave existing APIs in place with no plans to migrate them to using
> Result.
> 2. Aim to maintain both Result and Status APIs (backfill Result APIs where
> it makes sense).
> 3. Aim to migrate to Result APIs (backfill Result APIs and deprecate
> Status APIs). I assume this process will take at least 1 calendar year
> (its one of the things I'm hoping to get to). This is probably best done
> incrementally by submodule. I think for a change on this scale we should
> mark old APIs as deprecated and leave them in place for at least 2 release
> cycles (at the current cadence 6 months).
>
> For new APIs:
> 1. Attempt to always have both versions (Result and Status) of the API
> everywhere that it makes sense.
> 2. Produce both versions of the API until we are ready to deprecate Status
> APIs in one go.
> 3. Only produce APIs using Result.
>
> My personal preference would be to choose to use Result and proceed with
> Option 3 for existing APIs (aim for deprecation of Status) and Option 3 for
> new APIs (only use Result going forward). My second preference would be to
> simply remove "Result". I don't want to be supporting parallel APIs in the
> long term.
>
> Thanks,
> Micah
>
>
>
> On Sat, Oct 5, 2019 at 4:59 AM Sutou Kouhei <ko...@clear-code.com> wrote:
>
> > Hi,
> >
> > In <21...@python.org>
> > "Re: [DISCUSS] Result vs Status" on Sat, 5 Oct 2019 12:23:05 +0200,
> > Antoine Pitrou <an...@python.org> wrote:
> >
> > >> OK, so what could more context be provided on:
> > >>
> > >>> From the discussion in the sync call, it seems reasonable to require
> > that:
> > >>> Public APIs which are likely to be directly wrapped in a binding
> > should not
> > >>> use Result<> to the exclusion of Status. An equivalent Status API
> > should
> > >>> always be provided for ease of binding.
> > >
> > > I don't know, sorry :-) I wasn't on the sync call.
> >
> >
> > We don't need Status API for bindings. We already use
> > complex types such as std::shared_ptr in our API. Bindings
> > need C++ feature for complex types. So we don't need to care
> > about Result<> or Status.
> >
> >
> > Thanks,
> > --
> > kou
> >
Re: [DISCUSS] Result vs Status
Posted by Micah Kornfield <em...@gmail.com>.
Based on the call this week, I think there are a few related questions here.
1. Should we use Result at all?
- IMO Result expresses APIs more naturally then Status + Single output
parameter. I think most would agree if we had it from the beginning we
would be probably use it.
- The downside to using it is the pain in incorporating it into the
codebase, including the potential for inconsistent APIs and breaking
consumers of the package. It also has the potential to cause ABI problems
with other projects due its use of a vendored "Variant" implementations.
2. If we agree on using Result in the code-base going forward (i.e. we
don't remove it altogether), how do we move forward when working with APIs?
This can be divided into existing and new APIs.
For existing APIs we can:
1. Leave existing APIs in place with no plans to migrate them to using
Result.
2. Aim to maintain both Result and Status APIs (backfill Result APIs where
it makes sense).
3. Aim to migrate to Result APIs (backfill Result APIs and deprecate
Status APIs). I assume this process will take at least 1 calendar year
(its one of the things I'm hoping to get to). This is probably best done
incrementally by submodule. I think for a change on this scale we should
mark old APIs as deprecated and leave them in place for at least 2 release
cycles (at the current cadence 6 months).
For new APIs:
1. Attempt to always have both versions (Result and Status) of the API
everywhere that it makes sense.
2. Produce both versions of the API until we are ready to deprecate Status
APIs in one go.
3. Only produce APIs using Result.
My personal preference would be to choose to use Result and proceed with
Option 3 for existing APIs (aim for deprecation of Status) and Option 3 for
new APIs (only use Result going forward). My second preference would be to
simply remove "Result". I don't want to be supporting parallel APIs in the
long term.
Thanks,
Micah
On Sat, Oct 5, 2019 at 4:59 AM Sutou Kouhei <ko...@clear-code.com> wrote:
> Hi,
>
> In <21...@python.org>
> "Re: [DISCUSS] Result vs Status" on Sat, 5 Oct 2019 12:23:05 +0200,
> Antoine Pitrou <an...@python.org> wrote:
>
> >> OK, so what could more context be provided on:
> >>
> >>> From the discussion in the sync call, it seems reasonable to require
> that:
> >>> Public APIs which are likely to be directly wrapped in a binding
> should not
> >>> use Result<> to the exclusion of Status. An equivalent Status API
> should
> >>> always be provided for ease of binding.
> >
> > I don't know, sorry :-) I wasn't on the sync call.
>
>
> We don't need Status API for bindings. We already use
> complex types such as std::shared_ptr in our API. Bindings
> need C++ feature for complex types. So we don't need to care
> about Result<> or Status.
>
>
> Thanks,
> --
> kou
>
Re: [DISCUSS] Result vs Status
Posted by Sutou Kouhei <ko...@clear-code.com>.
Hi,
In <21...@python.org>
"Re: [DISCUSS] Result vs Status" on Sat, 5 Oct 2019 12:23:05 +0200,
Antoine Pitrou <an...@python.org> wrote:
>> OK, so what could more context be provided on:
>>
>>> From the discussion in the sync call, it seems reasonable to require that:
>>> Public APIs which are likely to be directly wrapped in a binding should not
>>> use Result<> to the exclusion of Status. An equivalent Status API should
>>> always be provided for ease of binding.
>
> I don't know, sorry :-) I wasn't on the sync call.
We don't need Status API for bindings. We already use
complex types such as std::shared_ptr in our API. Bindings
need C++ feature for complex types. So we don't need to care
about Result<> or Status.
Thanks,
--
kou
Re: [DISCUSS] Result vs Status
Posted by Antoine Pitrou <an...@python.org>.
Le 05/10/2019 à 01:40, Micah Kornfield a écrit :
>>
>>> It was my impression that we had workable solutions for using Result in
>> at
>>> least Python and Glib/Ruby (I'm don't know about R).
>>
>> In Python we do (though it needed a C++-side helper).
>>
> OK, so what could more context be provided on:
>
>> From the discussion in the sync call, it seems reasonable to require that:
>> Public APIs which are likely to be directly wrapped in a binding should not
>> use Result<> to the exclusion of Status. An equivalent Status API should
>> always be provided for ease of binding.
I don't know, sorry :-) I wasn't on the sync call.
Regards
Antoine.
Re: [DISCUSS] Result vs Status
Posted by Micah Kornfield <em...@gmail.com>.
>
> >
> > It was my impression that we had workable solutions for using Result in
> at
> > least Python and Glib/Ruby (I'm don't know about R).
>
> In Python we do (though it needed a C++-side helper).
>
OK, so what could more context be provided on:
> From the discussion in the sync call, it seems reasonable to require that:
> Public APIs which are likely to be directly wrapped in a binding should not
> use Result<> to the exclusion of Status. An equivalent Status API should
> always be provided for ease of binding.
Thanks,
Micah
On Thu, Oct 3, 2019 at 3:42 AM Antoine Pitrou <an...@python.org> wrote:
>
> Le 03/10/2019 à 06:13, Micah Kornfield a écrit :
> >
> > It was my impression that we had workable solutions for using Result in
> at
> > least Python and Glib/Ruby (I'm don't know about R).
>
> In Python we do (though it needed a C++-side helper).
>
> Regards
>
> Antoine.
>
Re: [DISCUSS] Result vs Status
Posted by Antoine Pitrou <an...@python.org>.
Le 03/10/2019 à 06:13, Micah Kornfield a écrit :
>
> It was my impression that we had workable solutions for using Result in at
> least Python and Glib/Ruby (I'm don't know about R).
In Python we do (though it needed a C++-side helper).
Regards
Antoine.
Re: [DISCUSS] Result vs Status
Posted by Micah Kornfield <em...@gmail.com>.
Hi Ben,
> From the discussion in the sync call, it seems reasonable to require that:
> Public APIs which are likely to be directly wrapped in a binding should not
> use Result<> to the exclusion of Status. An equivalent Status API should
> always be provided for ease of binding.
Along with other things on my backlog, I was hoping to get to moving most
APIs to use Result (i.e. slowly deprecating pass by pointers for simple
returns). I think think the exclusion is potentially places where there is
too high a performance overhead for the result (we haven't done any
measurement with it).
It was my impression that we had workable solutions for using Result in at
least Python and Glib/Ruby (I'm don't know about R). Is this not the case?
Thanks,
Micah
On Wed, Oct 2, 2019 at 10:43 AM Ben Kietzman <be...@rstudio.com>
wrote:
> The C++ library has two classes which fill mostly the same function. Both
> Status and Result<> are used to express a recoverable error in lieu of
> exceptions. Result<> is slightly more ergonomic in C++, but our binding
> infrastructures assume Status based APIs.
>
> From the discussion in the sync call, it seems reasonable to require that:
> Public APIs which are likely to be directly wrapped in a binding should not
> use Result<> to the exclusion of Status. An equivalent Status API should
> always be provided for ease of binding.
>