Re: [RFC PATCH 1/1] Add a type for errors

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Oct 3, 2024, 05:14 UTC
Message-ID: <CAPig+cQjk5_VJ-LNc9Hx3Q4n6H5bgg5cAztWhFpuweG8wFTjMw@mail.gmail.com>
In-Reply-To: <Zv3IHd0c4_0NPjOK@tapette.crustytoothpaste.net>

On Wed, Oct 2, 2024 at 6:24 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 24 quoted lines

> On 2024-10-02 at 22:16:00, Eric Sunshine wrote:
> > I'm not sure I understand your response to Phillip's observation.
> > Idiomatic error handling in Go:
> >
> >     if oid, err := repo_get_oid(r, "HEAD"); err != nil {
> >         return err;
> >     }
> >
> > seems much closer to Phillip's more succinct example than to the more
> > verbose example using GIT_ERROR_SUCCESS().
>
> I don't think that approach works if you want to use `oid`, since it
> scopes just to the `if` statement (and any relevant `else`).  If `oid`
> were already defined, then you would need to omit the colon in `:=`, or
> the compiler would complain about "no new variables".
>
> That's why I usually see this:
>
>   oid, err := repo_get_oid(r, "HEAD")
>   if err != nil {
>       return err
>   }
>
> which is much more like what Phillip's more verbose example shows.

Yes, you often see that in Go, as well as:

    var oid oid_type
    var err error
    if oid, err = repo_get_oid(r, "HEAD"); err != nil {
        return err;
    }

which is very much in line with Phillip's succinct C example. But isn't this all beside the point?

Your proposal uses Rust as a model to justify the API choice in this RFC, but Phillip's point was that -- despite being perfectly suitable in Rust -- it is _not_ ergonomic in C. Rather than explaining how the proposed non-ergonomic API is superior to the ergonomic API in Phillip's example, you instead responded by saying that people in some other programming language (Go, in this case) have to deal with non-ergonomic error handling on a daily basis, therefore, a non-ergonomic API is good enough for Git's C programmers. But that is not a very convincing argument for choosing a non-ergonomic API for *this* project which is written in C, especially considering that a more ergonomic API has been presented (and is already in use in parts of the codebase).

That's why I said in my original response that I didn't understand your response to Phillip. You seem to be using a non-justification ("other programmers suffer, so Git programmers can suffer too") as a justification for a non-ergonomic design.