The paper for vector was started together with string, but at some point
the author (and Library Evolution) decided to pause the vector paper
until string was done. String was somewhat easier, since the value_type
of string is always a char and thus trivially constructible/copyable, etc.
Unfortunately the vector paper was never resumed.
I would expect that a paper that proposes `resize_and_overwrite` for
vector would be well received.

On 10.11.24 13:51, Jonathan Wakely via Std-Proposals wrote:
>
>
> On Sun, 10 Nov 2024 at 11:47, André Offringa via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
> On 10/11/2024 12:02, Jonathan Wakely wrote:
>>
>> On Sun, 10 Nov 2024, 10:54 Jonathan Wakely, <cxx_at_[hidden]> wrote:
>>
>>
>> On Sun, 10 Nov 2024, 10:06 André Offringa via Std-Proposals,
>> <std-proposals_at_[hidden]> wrote:
>>
>> Dear all,
>>
>> I'd like to float the idea to make it possible to
>> construct a
>> std::complex and a std::vector uninitialized. [..]
>>
>> std::ifstream file("myfile.bin");
>> std::vector<char> buffer(buffer_size);
>> file.read(&buffer[0], buffer_size);
>>
>>
>> This is exactly the use case that
>> string::resize_for_overwrite solves. I think there is already
>> a proposal to add a similar function to vector.
>>
>> The committee has seen lots of proposals for a tag that says
>> to leave a container uninitialised, and has always decided we
>> don't want that because it's too error-prone and risky.
>>
>>
>> Actually I misremembered, there was support for a tag type, but
>> resize_for_overwrite was preferred for string. See the discussion in
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1072r10.html#alternatives
>>
>
> Thanks for the response and the link, nice to see there seems
> support.
>
> Has the complex type ever been mentioned in such discussions? Imho
> it is currently a more fundamental problem that can't be worked
> around. It might be simpler to solve since there's no allocator
> involved. For complex I also don't see a way around a tag, which
> might be another reason to introduce such a tag.
>
>
> Do you really care about the cost of initializing one std::complex
> variable?
> Surely it's only a problem when initializing large arrays or
> containers or std::complex? So if std::vector allowed you to avoid the
> default initialization of its lements, then
> std::vector<std::complex<double>> would be able to avoid initializing
> any std::complex values until you need them. No changes to
> std::complex are required.
>
> N.B. I think std::bit_cast<std::complex<double>> already allows you to
> get a std::complex<T> from T[2], and std::start_lifetime_as might do
> too. So the problems you describe with reinterpret_cast can be
> avoided, by not using reinterpret_cast. There are better tools for
> what you want to do there.
>
>
> Also, do you happen to have a link to report where the discussion
> for vector takes place?
>
>
> ISO meeting discussions are not publicly available, sorry.
>
>
> I had seen the method name resize_and_overwrite() but I had not
> realized it was intended to solve this problem. It doesn't have an
> easy name...
>
>
> That's intentional, because it's easy to misuse and create undefined,
> so it should require a verbose and non-ergonomic name, so that people
> only use it when they really need it and they know what they're doing.
>
> But if vector had it, it would solve the problem I have. It's imho
> not as readable as a tag constructor but still a good solution.
>
The tag constructor design was in an earlier version of the paper that
introduced `resize_and_overwrite` and was explicitly and purposefully
removed. It would make vector a much less safe type to deal with.


> Regards,
> André
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>