shouldn't this be allocator_type &alloc here, so we use the same allocator instance to deallocate the detached storage as the one that allocated it and was passed in the detached_storage_ptr to the constructor at line 745. In essence the vector created with this special constructor should continue using the same allocator instance that was used to allocate the buffer I think. This is to address the case of stateful allocators.

Well, it is more complicated than that, but I think we can't just assume that creating a new allocator is acceptable in all cases. Maybe we need to have alternative constructors for detached_storage_deleter , including one that takes a rvalue for the allocator.

Still this PR is better than the previous code. Maybe we can merge this and address remaining issues later. I am travelling and I can't investigate this as well as I'd like.

I think here shouldn't be an allocator reference because

1. After steal_data, the vector turns into a "null" state and can be deconstruted. If so, the allocator instance is also deconstruted and the allocator reference will dangling.
2. A reference member makes the deleter not default constructible, and this also propagates to the unique_ptr, which is not very easy to use.

Here, when the deleter is constructed, only the allocator is copied instead of the whole vector::Impl. I think copy the allocator is OK because all sane allocators passed to a container are stateless (because the standard API not plays well with stateful allocators, e.g. vector constructor copys an allocator, and vector::get_allocator also returns a copy of the allocator).

Actually here detached_storage_deleter can be more compact by marking alloc as [[no_unique_address]], since stateless allocators often have no data members. For example, std::allocator.

Still this PR is better than the previous code. Maybe we can merge this and address remaining issues later. I am travelling and I can't investigate this as well as I'd like.

OK, just take your time. It's not urgent.