>
> Real usage for me of this feature would be reduce size of
> `std::vector` as in this case you could avoid `capacity` duplication
> in vector.
> Of corse this will work only if allocator used `new[]` instead other
> manual handling, but even in this case allocator should perhaps know
> how big array is?
>

Any container can already do this by rebinding and putting additional
header information in front of the allocation. However, it's more work and
means that accessing the capacity requires memory indirection, which
probably slows down operations like push_back that need to check whether
the capacity is sufficient.



> Another case is recent `std-big-int` discursion on proposal mailing
> list and its reference implantation:
> https://github.com/eisenwave/std-big-int
>
> where we have members like:
> ```
> std::uint32_t m_capacity; //
> 0 = static storage, >0 = heap capacity
> std::uint32_t m_size_and_sign; //
> bit 31 = sign, bits 0-30 = limb count
> data_type m_storage;
> BEMAN_BIG_INT_NO_UNIQUE_ADDRESS allocator_type m_alloc;
> ```
> Idea was if we have static storage then `m_capacity` is pointless, if
> we have heap then it could be on heap too.
> But then if its on heap do it not already have this value to handle
> `delete[]`?
>

It's not pointless; it's a trade-off. In the 64-bit case, removing the
capacity here is also buying you no size reduction because m_storage is
aligned to 64 bits anyway, so you'd end up with a 32-bit size and 32 bits
of padding.

In the 32-bit case, it's not so obvious, but having direct and
unconditional access to the capacity buys you something.