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.
>
|