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 >
