[libcxx-commits] [libcxx] [libc++] Implement P0843R14: `inplace_vector` (PR #204008)

William Tran-Viet via libcxx-commits libcxx-commits at lists.llvm.org
Fri Jun 19 09:56:40 PDT 2026


smallp-o-p wrote:

> Just for the record, I'd really like us to look into making this type as compact as possible before making the ABI stable. Specifically, I'd like us to explore:
> 
>     * putting the size into the tail padding of the last object
> 
>     * using tombstone traits to check whether the last element exist and if not have a size variable there. If it exists we know that we're full.
> 
> 
> If people have more ideas how to make this compact I'm happy to talk about that as well of course.

I've done some thinking on the methods you proposed:

> putting the size into the tail padding of the last object

This one is (I think) impossible because `data()` is a public API, meaning for an `inplace_vector<T,N>` with `size()` == `N` it's valid to write to `data()[N-1]`, where the padding bits would then get zeroed and corrupt the vector's state. I'm also unsure of an approach to this that is `constexpr` friendly since `[[no_unique_address]]` doesn't apply for C arrays, which leaves us with `reinterpret_cast` shenanigans which I believe will always run into UB.

> using tombstone traits to check whether the last element exist and if not have a size variable there. If it exists we know that we're full.

This one I think is doable but we'd be limited to `size_type`s where `sizeof(size_type)` <= `sizeof(T)`, which I think is valid for quite a few types in the standard library. I remembered you have #98498 open, but it's been a while, and I'd like to know if you want that work to finish first before continuing with `inplace_vector`, or if you're fine with letting this work get merged as experimental, and then adding `tombstone_traits` whenever that's done.

https://github.com/llvm/llvm-project/pull/204008


More information about the libcxx-commits mailing list