From dev-return-15545-archive-asf-public=cust-asf.ponee.io@arrow.apache.org Sat Oct 19 01:18:36 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 05A591804BB for ; Sat, 19 Oct 2019 03:18:35 +0200 (CEST) Received: (qmail 78960 invoked by uid 500); 19 Oct 2019 01:18:34 -0000 Mailing-List: contact dev-help@arrow.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@arrow.apache.org Delivered-To: mailing list dev@arrow.apache.org Received: (qmail 78947 invoked by uid 99); 19 Oct 2019 01:18:34 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 19 Oct 2019 01:18:34 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id BFDB1C1CFA for ; Sat, 19 Oct 2019 01:18:33 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 1pYEltwS3O5r for ; Sat, 19 Oct 2019 01:18:31 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.167.41; helo=mail-lf1-f41.google.com; envelope-from=emkornfield@gmail.com; receiver= Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id B0BE7BC58D for ; Sat, 19 Oct 2019 01:18:30 +0000 (UTC) Received: by mail-lf1-f41.google.com with SMTP id t8so5962977lfc.13 for ; Fri, 18 Oct 2019 18:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=V0PCw7XoEWSNIjEjRSOy0w9tTp6oNr4SZ0wSOyVFUsE=; b=UqOIOse4ysRKdgaGjJ9r+yNQT3RkUYxhKEFqcNHohnU21SupvD1wasY4zqn7kVD332 wmtdV+hnTy4wRrF0QBBq8FqcfDLY7QZYy1FPwuD4EhKj3A+xVQvvVoV8wdjRsFcr5uW/ LRwqo+/1N4N2DUWZqtIvsw+hUTPh5OILlqvp+tgIxmeGfq88oGkxtpNwdcccqkJ0Zxme S+2hsViWbsv1fOrT7KduMINm4gwg7Gp2nbWfvZw0FPcIitr7xkRbRszYt0NAeSCkCoyU QefXf96OMSleq6VIzyhvnl4T//lejF2qHyxqsWo1Vz8k87wMisOa9cy0qN+oLVsl1nJH SNOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=V0PCw7XoEWSNIjEjRSOy0w9tTp6oNr4SZ0wSOyVFUsE=; b=frH9RmjlqByAnI/mMpoyTcR0IzpuXOpbOyIAePt0iP3nOV0yrGxo8U1XiVIvxOpTFp MnoZfC1eBv0v/8mwRDcHs/NeSQlUQPeTvflqd4PUbQUzfLhQBuhp44ZD2Thr7Y1UUIya mtDNkZciBo+vrjYJ0oIPbnyozoIWygh04mojXkRK82rQpUU6kFO0fnILe/7Q7sc+wpm+ 6zIStPcaRmXfBlYaU12Ja9ThNdoUql8uvAo9wQ21ncj/RTjNYUcRtkzhaqgvQjHRGUya NHMnHAMpwRzGhtQ5eduuo9gxi1vTxM+h/zDoS+2hJgfzQrXR+0ZvzjtFb2mvfgYknDTo o6hw== X-Gm-Message-State: APjAAAUFfDf9JvMuVXMW7QPHJBPlQUYj+cf94cwe/l/yriFJ9xTdDfUK lavEKHLK0G27leyMYOM3KB6SGyGvI2ez7yJogro= X-Google-Smtp-Source: APXvYqx5bHYopgigHUtYds+Uk0Bebiv7O/gCm10THyZS6XbRhQM/S1pyNTP1+95wqjz+vqdni1QpMzQygXqqXp/JafA= X-Received: by 2002:a19:7513:: with SMTP id y19mr7300820lfe.99.1571447909325; Fri, 18 Oct 2019 18:18:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:1681:0:0:0:0:0 with HTTP; Fri, 18 Oct 2019 18:18:28 -0700 (PDT) Reply-To: emkornfield@gmail.com In-Reply-To: References: <5d8a8aa2-0c36-3e37-a4df-2663d4505389@python.org> <21183bb1-813f-b35b-b391-3f52ef2e62c9@python.org> <20191005.204934.1720707226652785828.kou@clear-code.com> From: Micah Kornfield Date: Fri, 18 Oct 2019 18:18:28 -0700 Message-ID: Subject: Re: [DISCUSS] Result vs Status To: Wes McKinney Cc: dev Content-Type: multipart/alternative; boundary="0000000000006b231a0595393a64" --0000000000006b231a0595393a64 Content-Type: text/plain; charset="UTF-8" Hi Wes, Sorry for the confusion I agree completely with what you wrote. I was only thinking about scenario 2 and 3 (where it makes sense) in my previous email. TL;DR; in the long term I don't think we should be supporting semantically equivilent APIs for both Status and Result. I'll see if I can get an estimate of APIs that would change Thanks, Micah On Friday, October 18, 2019, Wes McKinney wrote: > On Fri, Oct 18, 2019 at 7:58 PM Wes McKinney 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 has to be a struct-like value that transports > > multiple pieces of data > > * "Out" data may be split across a Result and a separate out > > argument. That's not too nice > > > > Can't say I'm thrilled about having Result 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 > 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 > wrote: > > > > > > > Hi, > > > > > > > > In <21183bb1-813f-b35b-b391-3f52ef2e62c9@python.org> > > > > "Re: [DISCUSS] Result vs Status" on Sat, 5 Oct 2019 12:23:05 +0200, > > > > Antoine Pitrou 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 > > > > > --0000000000006b231a0595393a64--