Someone coming from a garbage-collected programming language does not expect memory to be freed anytime soon at all.   -----Ursprüngliche Nachricht----- Von:Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 08.10.2025 07:03 Betreff:Re: [std-proposals] Proposal: Clarifying or Deprecating clear() in STL containers An:std-proposals_at_[hidden]; CC:Simon Schröder <dr.simon.schroeder_at_[hidden]>;  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 -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals