You (or your copilot) seem to have missed the point behind object
lifetimes. The vector values' lifetimes are being ended. They no longer
exist.

There exists a residual bit pattern in that space that you're mistaking for
the values that used to be there.

Your "radical fix" is to force it to do extra work, paging in memory and
invalidating cache lines, for memory that does not contain any live
objects. I do not think there is any value in that, especially not given
that C++26 has added hardened preconditions that actively stop you from
even looking at those values inside your software without first creating a
new object in their space invalidating the data currently there.

Even the "soft fix" is adding documentation to a function that has been
used for over a quarter century. If people haven't been able to understand
what it does by now... I don't think adding that to documentation - or the
c++ standard, which seems to be what you're suggesting? - is of any meaning.

Not to mention that this function has 25+ years of deployment and
experience. Have you tried searching for how often this is used in any code
anywhere?

PS: I do not care whether you use any AI tools. I will assume you are
taking full responsibility for what your email contains regardless if you
used autocorrect, autocomplete or auto-write-my-whole-proposal. And your
remaining goodwill will reduce if it's terrible.

On Tue, 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
>