On Mon, Aug 25, 2025 at 4:40 PM Ezekiel Newren <ezekielnewren@xxxxxxxxx> wrote: > > On Sun, Aug 24, 2025 at 7:31 AM Ben Knoble <ben.knoble@xxxxxxxxx> wrote: > > I’m mildly surprised Vec isn’t a good fit: isn’t it a pointer, length, capacity triple? But it sounds like the main issue is allocator interop… which I would also have thought was supported? At least the current version is documented as being generic against an Allocator, too. > > Conceptually yes, semantically and syntactically no. On top of Vec<T> > not being defined with #[repr(C)] (which ensures field order, C ABI > layout, padding, etc...) the struct definition for Vec isn't constant > between Rust versions. I'd be open to suggestions for an alternative > to my ivec type. Ah, thanks—I had forgotten about the #[repr(C)] needs and changes. Makes sense. > > 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). Thanks! -- D. Ben Knoble
