We obviously can't deprecate `clear()`, nor change its behavior by fiat.
That ship sailed very long ago, and `clear()` is a *very* widely used
method.

However, you're right that its semantics are generally underspecified and
there is (very slight) vendor divergence:
https://quuxplusone.github.io/blog/2025/01/02/shrink-to-fit/#how-do-i-clear-and-free-in-one-line

And you're right that in industry code it's usually desirable to (1) have a
specific idiom for clearing-and-deallocating, and (2) always know what is
the effect of the code you write. That is, in industry sometimes we don't
want to use `.clear()` because its effect is ambiguous for the reader, and
sometimes we want something that's not `.clear()` because we specifically
need to clear-and-deallocate.
So it would certainly be nice, in a vacuum, to have an API like
    v.resize(0); // does not change the capacity
    v.clear(); // resets the container to its default-constructed state
or perhaps (yucky, but I've seen exactly this in the wild)
    v.clear(); // does not change the capacity
    v.reset(); // resets the container to its default-constructed state

But I don't think we have any practical route to get there with the STL
itself. You're welcome to come up with some wording and explain how you
think it's a plausible practical first step up the cliff.

Finally: You seem to think that someone might expect `v.clear()` to do the
equivalent of
    std::fill(v.begin(), v.end(), {});
or
    std::destroy(v.begin(), v.end());
    std::uninitialized_default_construct(v.begin(), v.end());
or something like that. I disagree with your prediction; I don't think
anyone expects `v.clear()` to work that way. I also don't think anyone
*wants* a concise way to spell that operation. So that part of your
message/semi-proposal is a red herring and (IMO) you should just eliminate
it.

HTH,
Arthur


On Tue, Oct 7, 2025 at 4: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
>