Date: Wed, 8 Oct 2025 07:02:36 +0200
First of all, we don‘t ever break existing code willy-nilly. .clear() already has a meaning and it will not change. C++ is meant for high performance and it is a good thing that .clear() does not free the memory. (At least when it is reused.) std::vector has shrink_to_fit() to (maybe) free the memory after a call to .clear(). But, even this is not really necessary as there is the well-known swap-trick to immediately free the memory of a vector. Sure, this is not intuitive for someone coming from a different programming language, but it is expected knowledge (depending on the field where C++ is used) of an experienced C++ programmer.
> On Oct 7, 2025, at 10: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
> On Oct 7, 2025, at 10: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
Received on 2025-10-08 05:02:53
