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

[Eric Sunshine <sunshine@sunshineco.com>]

On Wed, Oct 2, 2024 at 6:24 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> 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.