Stabilized soon, really? They did not stabilize it after 10 years and were thinking about different approach. I thought it’s dead.

You can’t allocate collections without nightly or without reimplementing them in the library. Every implementation uses it’s own set of trade offs to provide safety in unsafe implementation.

There are more than 10 crates for arenas with different tradeoffs, I'm well aware of them. They are still very limited compared to C/Zig.

Things are cheap until they are someone else’s problem, I say!

Even in C, if you want differently sized data to be indexable in O(1), you're stuck leaving them as pointers. You definitely could just have a variable-sized area for this, but that level of optimization is pretty seldomly done in C.

I think they mean the cache entry is a collection of dynamically sized fields. It would be nicer to store that as a single contiguous allocation, rather than a bunch of pointers to individually allocated dynamically sized items. At least in this case, it might.

In a row oriented database, you get a contiguous spot for the whole row even when there are multiple variable width fields.

There are various ways of implementing this, someone from a C programming background mentioned on option where the heap-allocated record objects aren't fixed size structs, but instead the allocated space is dynamically sized and the struct is just a prefix.

So logically you'd have the equivalent of:

    struct FooRecord {
        int fixed_sized_field;
        char some_other_field;
        string first;
        string last;
        string title;
    }

    struct FooRecord {
        long __length__;
        int fixed_sized_field;
        char some_other_field;
        char* first;
        char* last;
        char* title;
    }

There are variants of the above, of course. Instead of pointers the compiler could use lengths, offsets, or a pointer to the end of the variable length field -- this works because the beginning of the first field is at a fixed offset, and then pairs of pointers delimit the rest.

You can rely on the heap allocator to track the "__length__" instead, or you can encode it into the record explicitly to make "dynamic sized copies" simple.

Windows APIs generally work this way! You create a buffer, put a length in the first field, and then the API call writes a fixed-sized prefix followed by the dynamic-sized fields into the buffer. The 'length' is replaced too, so you know how many bytes to copy out without having to understand the structure.

Database engines go one step further and pack multiple "records" into a single "row". They typically store the fields "packed" at the start of the row with 16-bit length or offset markers at the end for the various dynamic sizes.

Something like:

    fixed_sized_field // Row #0
    some_other_field
    first
    last
    title
    fixed_sized_field // Row #1
    some_other_field
    first
    last
    title
    ... empty space ...
    next_offset      // always populated
    row#1_title_offset
    row#1_last_offset
    row#1_first_offset
    row#1_offset
    row#0_title_offset
    row#0_last_offset
    row#0_first_offset
    row#0_offset  // typically the constant zero