P0843 inplace_vector (draft)

[vasama]

• Added <inplace_vector> according to P0843
• Copied the constexpr vector unit test with some changes.
• The constexpr tests don't yet work due to the use of public uninitialized_* functions from <memory>.
  The _Uninitialized_* from <xmemory> require an allocator parameter which we don't have here.
  Should we
  • fake the allocator and use those functions, or
  • add non-allocator aware versions of those functions, or
  • do something else entirely?
• Left TODO comments in the code for open questions:
  • The aforementioned <memory> functions usage.
  • _Inplace_vector_nontrivial_dummy_type is a duplicate of _Nontrivial_dummy_type in <optional>.
  • _Inplace_vector_value_init_tag is a duplicate of _Value_init_tag in <vector>.
• I noticed that vector::pop_back checks for _ITERATOR_DEBUG_LEVEL and not _CONTAINER_DEBUG_LEVEL. I followed suit, but is that intended?

I'm aware that you're prioritising C++23 features for now. This PR will just be waiting in the meantime.

[vasama]

@microsoft-github-policy-service agree

[frederick-vs-ja]

Thank you!

I think I can answer these questions.

Once MSVC STL start to accept PR for C++26 features, <yvals_core.h> and corresponding feature test macro test file should also be updated.

[frederick-vs-ja]

If we don't want constexpr to be blocked, perhaps we should add _Uglified constexpr versions of these standard algorithms in <xmemory> and add // TRANSITION, P2283 comments. This will allow us to include <xmemory> only.

But I think the used algorithms should be moved to <xmemory> eventually.

[frederick-vs-ja]

This is probably buggy, see #4847. How about changing iterator types to _Inplace_vector_iterator::_Iterator<_IsConst> and provide comparison operators as hidden friends?

[vasama]

inplace_vector<expected<any, char>, 1> cont{};
(void) (cont.begin() == cont.end());

This works. Is that good enough?

[StephanTLavavej]

I appreciate the enthusiasm, but in #4766 we clearly explained:

Note: We're focused on implementing the remaining library-only features in C++23. Until that's done, we will NOT be accepting PRs for C++26 features.

It's going to be a while before we can accept C++26 PRs. I think it'll be distracting and unproductive (as merge conflicts accumulate) to keep a PR open for what's likely to be more than a year, so I'm going to go ahead and close this. You're welcome to resubmit a PR when we begin work on C++26.