On Tue, 7 Oct 2025 at 21:12, 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().
>

It would be helpful if you were explicit that you're talking about the
sequence containers. For the associative containers (i.e. the maps and
sets) clear() is already specified to be equivalent to erase(begin(),
end()).


>
> *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.
>
I've never seen anybody confused about that, can you show any evidence of
that?



> This confusion is compounded by the fact that clear() does not offer
> anything beyond what erase(begin(), end()) already provides.
>

That's not true. It has weaker preconditions, as you can clear() a
container of non-move-assignable elements, but you can't call erase(i, j)
on all such containers.


>
> *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.*
>
>
What is this nonsense? clear() has been around just as long as erase(first,
last).

https://stl.boost.org/Sequence.html


> *Proposal*
>
> - *Option A (radical)*:
> - Deprecate or remove clear() from STL containers where it is strictly
> equivalent to erase(begin(), end())
>
> This would be a major breaking change for no benefit whatsoever.

It's also not equivalent, because clear() has no preconditions (except that
the elements are destructible, which is required by the container already).
For some standard containers, erase(i, j) requires the elements to be move
assignable, because it's a more general operation that can remove a subset
of the elements from anywhere in the sequence. clear() doesn't need to move
anything, it just destroys all the elements.


>
> -
> - 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.
>
>
This would be even worse. Nobody wants that behaviour, and it's not what
resize(n, val) does.


>
> -
> - *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.
>
>
That would be incorrect, because it would imply that vector<T>::clear()
requires T to be move assignable, which is false.

The sequence container requirements are already clear (no pun intended)
that a.clear() "Destroys all elements in a." and ensures the postcondition
that a.empty() is true.