On Fri, Oct 18, 2019 at 7:58 PM Wes McKinney <wesmck...@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 <emkornfi...@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 <k...@clear-code.com> wrote: > > > > > Hi, > > > > > > In <21183bb1-813f-b35b-b391-3f52ef2e6...@python.org> > > > "Re: [DISCUSS] Result vs Status" on Sat, 5 Oct 2019 12:23:05 +0200, > > > Antoine Pitrou <anto...@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 > > >
