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

Nikolas Klauser via libcxx-commits libcxx-commits at lists.llvm.org
Sat Jun 20 00:14:08 PDT 2026


philnik777 wrote:

> 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.

AFAIK that's only allowed when constructing or destructing the object, which users aren't allowed to do. Note that There are some types which have padding, but the Itanium ABI doesn't allow the use of them. I believe these are the only ones where writing to the padding at any point is allowed.





> 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.

I want to work on this, but it's non-trivial to do. I'm happy to land this first as experimental and then try to do the shenanigans I'm proposing here.

> We may also have to take some care about making sure the `size` variable doesn't interfere with the state that represents if an item is dead or not, e.g. It'd be impossible(?) to distinguish between a `bool == false`, and a size variable who's value is 0.

That is part of what the tombstone traits should handle.



> Another question would be how we would also provide a `data()` member since we'd certainly need a `union { T, __size_type }` to represent this.

I'm not quite sure what you're concerned about. We can always construct a different object in the space T takes, without any unions.

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


More information about the libcxx-commits mailing list