From: Junio C Hamano Date: Tue, 28 Oct 2025 20:20:58 GMT Subject: Re: [PATCH 03/14] hash: use uint32_t for object_id algorithm Message-ID: In-Reply-To: Ezekiel Newren writes: >> I suspect that it would be much more palatable if these functions >> and struct members are to use a distinct type that is used only by >> hash algorithm number (your "enum" is fine), that is typedef'ed to >> be the 32-bit unsigned integer, e.g, >> >> +typedef uint32_t hash_algo_type; >> -int hash_algo_by_name(const char *name) >> +hash_algo_type hash_algo_by_name(const char *name) >> >> Yeah, I know that C does not give us type safety against mixing two >> different things, both of which are typedef'ed to the same uint32_t, >> but doing something like the above would still add documentation >> value. > > I'm against passing Rust enum types over the FFI boundary since Rust > is free to add extra bytes to distinguish between types (and it's > documented by Rust as not being ABI stable). It's OK for you to be against it. My mention of "enum" was enum on the purely C-side and I didn't have Rust's enum in mind at all. As Brian defined ObjectID on the Rust side, the type tag was done as u32, IIUC, not Rust's enum.