Date: Tue, 07 Oct 2025 21:56:41 +0100
Hello Don't rush when you answer.Please re-read the proposal, and try to understand the writer intent.Sent from my Galaxy
-------- Original message --------From: Rhidian De Wit via Std-Proposals <std-proposals_at_[hidden]> Date: 10/7/25 9:38 PM (GMT+01:00) To: std-proposals_at_[hidden] Cc: Rhidian De Wit <rhidiandewit_at_[hidden]> Subject: Re: [std-proposals] Proposal: Clarifying or Deprecating clear() in STL containers Even further, the Notes section of clear() clarifies further:Calling clear() does not affect the result of capacity(). The standard's restriction on the changes to capacity is in the specification of reserve(), see SO.So, I feel like no clarifications to the standard are needed, let alone actual changesOp di 7 okt 2025 om 22:35 schreef Rhidian De Wit <rhidiandewit_at_[hidden]>:Isn't cppreference quite clear about what clear() does?Erases all elements from the container. After this call, size() returns zero.Invalidates any references, pointers, and iterators referring to contained elements. Any past-the-end iterators are also invalidated.it never specifies anything about releasing memory, or resetting values.Best,RhidianOp di 7 okt 2025 om 22:12 schreef Jerome Saint-Martin via Std-Proposals <std-proposals_at_[hidden]>:
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
-------- Original message --------From: Rhidian De Wit via Std-Proposals <std-proposals_at_[hidden]> Date: 10/7/25 9:38 PM (GMT+01:00) To: std-proposals_at_[hidden] Cc: Rhidian De Wit <rhidiandewit_at_[hidden]> Subject: Re: [std-proposals] Proposal: Clarifying or Deprecating clear() in STL containers Even further, the Notes section of clear() clarifies further:Calling clear() does not affect the result of capacity(). The standard's restriction on the changes to capacity is in the specification of reserve(), see SO.So, I feel like no clarifications to the standard are needed, let alone actual changesOp di 7 okt 2025 om 22:35 schreef Rhidian De Wit <rhidiandewit_at_[hidden]>:Isn't cppreference quite clear about what clear() does?Erases all elements from the container. After this call, size() returns zero.Invalidates any references, pointers, and iterators referring to contained elements. Any past-the-end iterators are also invalidated.it never specifies anything about releasing memory, or resetting values.Best,RhidianOp di 7 okt 2025 om 22:12 schreef Jerome Saint-Martin via Std-Proposals <std-proposals_at_[hidden]>:
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 -- Rhidian De WitSoftware Engineer - Barco -- Rhidian De WitSoftware Engineer - Barco
Received on 2025-10-07 20:56:52
