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