wt., 7 paź 2025 o 23:10 Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> We obviously can't deprecate `clear()`, nor change its behavior by fiat. That ship sailed very long ago, and `clear()` is a very widely used method.
>
> However, you're right that its semantics are generally underspecified and there is (very slight) vendor divergence:
> https://quuxplusone.github.io/blog/2025/01/02/shrink-to-fit/#how-do-i-clear-and-free-in-one-line
>
> And you're right that in industry code it's usually desirable to (1) have a specific idiom for clearing-and-deallocating, and (2) always know what is the effect of the code you write. That is, in industry sometimes we don't want to use `.clear()` because its effect is ambiguous for the reader, and sometimes we want something that's not `.clear()` because we specifically need to clear-and-deallocate.
> So it would certainly be nice, in a vacuum, to have an API like
> v.resize(0); // does not change the capacity
> v.clear(); // resets the container to its default-constructed state
> or perhaps (yucky, but I've seen exactly this in the wild)
> v.clear(); // does not change the capacity
> v.reset(); // resets the container to its default-constructed state
>
> But I don't think we have any practical route to get there with the STL itself. You're welcome to come up with some wording and explain how you think it's a plausible practical first step up the cliff.
>
> Finally: You seem to think that someone might expect `v.clear()` to do the equivalent of
> std::fill(v.begin(), v.end(), {});
> or
> std::destroy(v.begin(), v.end());
> std::uninitialized_default_construct(v.begin(), v.end());
> or something like that. I disagree with your prediction; I don't think anyone expects `v.clear()` to work that way. I also don't think anyone wants a concise way to spell that operation. So that part of your message/semi-proposal is a red herring and (IMO) you should just eliminate it.
>

Question is would be `x = {};` prefered way to clear the container?
It should move the temp object that is empty to the current one.

And this would work for many types that have constructor that do not
take parameters.

> HTH,
> Arthur
>
>
> On Tue, Oct 7, 2025 at 4:12 PM Jerome Saint-Martin via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Motivation
>> In the Standard Template Library (STL), the clear() function is defined for containers like std::vector, std::deque, and others. Its behavior is functionally equivalent to:
>> container.erase(container.begin(), container.end());
>>
>> It removes all elements from the container, reducing its size() to zero, but does not release memory (capacity remains unchanged), nor does it reset values. This leads to a subtle redundancy in the API: clear() is essentially a shorthand for a full-range erase().
>>
>> Observation
>> While clear() is widely used and syntactically convenient, it introduces a semantic ambiguity. Many developers — especially those new to C++ — assume clear() “resets” the container’s values. In reality, it destroys the elements, not reinitializes them.
>> This confusion is compounded by the fact that clear() does not offer anything beyond what erase(begin(), end()) already provides.
>>
>> Too Much Progress Kills the Progress
>>
>> In the early days of programming, we used erase(begin(), end()) like our ancestors used silex to make fire. It was precise, intentional, and part of the craft. Then came clear() — a smoother, more modern tool. But in simplifying, we may have blurred its purpose. Today, we have expressive tools like resize(n, val), ranges, and lambdas.
>>
>> Proposal
>>
>> Option A (radical):
>>
>> Deprecate or remove clear() from STL containers where it is strictly equivalent to erase(begin(), end())
>> reclaim clear() for a more meaningful role — resetting vector values to a default value, like resize(n, val) does — and let erase(begin(), end()) remain the sharp silex in our toolbox.
>>
>> Option B (soft): Clarify in the standard documentation that clear() is a semantic alias for erase(begin(), end()), and does not reset values or release memory.
>>
>>
>> std::co_proposers :: Jérôme Saint-Martin and friend Beg Copilot
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals