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, 03 Oct 2019 04:13:18 GMT
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 <ben.kietzman@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.
>

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