Re: [PATCH 04/14] rust: add a ObjectID struct

From: Patrick Steinhardt <ps@pks.im>
Date: Oct 29, 2025, 09:08 UTC
Message-ID: <aQHZda5I0JPSRwv1@pks.im>
In-Reply-To: <aQFhpAinB6HLC-Tw@fruit.crustytoothpaste.net>

On Wed, Oct 29, 2025 at 12:36:52AM +0000, brian m. carlson wrote:

Show 20 quoted lines

> On 2025-10-28 at 09:17:03, Patrick Steinhardt wrote:
> > We typically don't have these headers for our C code, so why have it
> > over here?
> 
> This is explained in the cover letter.
> 
> > An alternative to represent this type would be to use an enum:
> > 
> >     pub enum ObjectID {
> >         SHA1([u8; GIT_SHA1_RAWSZ]),
> >         SHA256([u8; GIT_SHA256_RAWSZ]),
> >     }
> > 
> > That would give us some type safety going forward, but it might be
> > harder to work with for us?
> 
> I agree that would be a nicer end state, but that can't be cast from C,
> which we do later in the series.  The goal is to have a type that is
> suitable for FFI between C and Rust and we will be able to switch once
> we have no more C code using this type.

Fair.

I'm mostly asking all of these questions because this is our first Rust code in Git that is a bit more involved. So it's likely that this code will set precedent for how future code will look like, and ideally I'd like us to have code that is idiomatic Rust code.

With the FFI code it's of course going to be a mixed bag, as we are somewhat bound by the C interfaces. But in the best case I'd imagine that we have low-level FFI primitives that bridge the gap between C and Rust, and then we build a higher-level interface on top of that which allows us to use it in an idiomatic fashion.

I guess all of this will require a lot of iteration anyway as we gain more familiarity with Rust in our codebase. And things don't have to be perfect on the first try *shrug*

Thanks!

Patrick