Re: [PATCH v3 06/15] ivec: create a vector type that is interoperable between C and Rust

[Ezekiel Newren <ezekielnewren@gmail.com>]

On Tue, Aug 26, 2025 at 7:30 AM D. Ben Knoble <ben.knoble@gmail.com> wrote:
> > > Am I reading the patch correctly that the ivec implementation is primarily C? I’m not familiar with too many FFI projects in Rust, but I might have hoped we could write parts in Rust to gain any benefits from that, too. Is that a fool’s errand I’m thinking of?
> >
> > The ivec type is defined and implemented in C (interop/ivec.[ch]) and
> > Rust (rust/interop/src/ivec.rs). When I started writing the ivec type
> > I didn't know if the Git community would accept a hard dependency on
> > Rust, so I made ivec usable in C without needing Rust.
>
> Right—I saw both implementations, but it looked like C did most of the
> work, which was my main question. Re-reading, it looks like Rust does
> more work than I thought (with implementations of insert/push/etc.)
>
> That said, I think it's sensible to leave the type useable from just C
> unless/until Rust becomes required (and then we can move things over).

I like your idea of implementation consolidation. I just don't know
what that would look like yet.

It's not straightforward because C doesn't have generics. I'll use
IVec as an example, but this applies to any generic type in Rust. For
a function like push() in IVec<T> it will have N definitions if there
are N IVec types. e.g. If your code uses IVec<u64>, IVec<u8>,
IVec<i32> that would mean that pub fn push(&mut self) {} would compile
to 3 functions. If you don't use #[no_mangle] you'd have to figure out
the Rust compiler's exact behavior for function names when calling it
from C, which isn't stable or easily predictable. If you do use
#[no_mangle] then the Rust compiler can't generate a generic function
for each type.

Another problem is that the functions in ivec mostly deal with
resizing the memory rather than controlling access to memory for the C
side. Even if the C side used Rust defined functions, that wouldn't
solve memory access issues to the pointer on the C side. We could
enforce access to each element by requiring C to call a Rust defined
function for each element, but that sounds very painful and slow. ivec
is meant to be used as a scaffolding type to help transition C to
Rust.

Other projects that do use Rust's builtin Vec (or some other
collection type) often Box it and write wrapper functions. This means
that the C side sees an opaque void* instead of a transparent struct
like ivec with ptr, length, capacity, and element_size.

I'm curious if the community has more design feedback, or suggestions
for an alternative to my ivec type.