On 2025-08-26 at 18:47:06, Ezekiel Newren wrote: > I'm curious if the community has more design feedback, or suggestions > for an alternative to my ivec type. I think this is a fine approach. We used a similar Vec<u8>-like structure when porting a service from C to Rust at $DAYJOB, but we've also used the boxing approach to good success. Ultimately, I think boxing is the right choice when we don't need access from C. For instance, if I were to convert the loose object mapping code to Rust, I would store the data as a pair of Box<HashMap<_, _>> and then attach them to struct repository as `void *`. But it's less definitive when you need access from C. Because of the way we intimately mess with the internals of our data structures in this codebase, the ivec is probably the right choice here, so I'd keep that. -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature